# Atlas error "Response decompression failed" (ZlibError): how to fix it > Retry: Atlas maps the ZlibError decompression failure to a retryable APIError. If it persists, bypass any proxy that re-compresses or truncates the response body. Atlas reports the APIError "Response decompression failed" with metadata code ZlibError when the gzip or deflate response body could not be inflated, and the fix is to retry, because Atlas maps FetchDecompressionError to a retryable APIError. If retries keep failing, suspect a proxy that re-compresses or truncates the response body, and bypass it for the provider host. If you aborted the request yourself, Atlas raises MessageAbortedError instead, which is not a failure. ## Symptom The message fails with an APIError whose message is "Response decompression failed" and whose metadata code is ZlibError. ## Cause A FetchDecompressionError with code ZlibError means the gzip/deflate body could not be inflated. Atlas's toError maps that to a retryable APIError, unless the request was aborted, in which case it becomes MessageAbortedError instead. ## Fix 1. Retry the message. The mapped error is retryable, so Atlas expects a second attempt to be worth making. 2. Suspect a proxy that re-compresses or truncates the response body. A gzip/deflate stream that has been rewritten in flight will not inflate. 3. Bypass the proxy for the provider host and retry the same message to confirm the proxy is the cause. 4. If you aborted the request yourself, expect MessageAbortedError instead of ZlibError. MessageAbortedError is not a failure and needs no fix. 5. Check the metadata code before acting: ZlibError means a decompression failure, and any other code points at a different Atlas error path. ## Why does Atlas report Response decompression failed Atlas reports "Response decompression failed" when a FetchDecompressionError with code ZlibError is raised, meaning the body could not be inflated under either of the 2 encodings, gzip or deflate. Atlas's toError maps that FetchDecompressionError to a retryable APIError, so the metadata code you see on the message is ZlibError. Providers compress their response bodies with gzip or deflate, and Atlas inflates them on arrival. When the compressed stream is malformed, incomplete, or has been rewritten in transit, the inflate step fails and Atlas gets a FetchDecompressionError carrying the code ZlibError. Rather than crash on a raw zlib fault, Atlas converts it into an APIError with the message "Response decompression failed" and marks it retryable. The important read here is that the model produced a response and the bytes came back. The bytes just did not survive decompression, which is a transport-layer problem and not a prompt or model problem. ## How to fix Response decompression failed in Atlas Step 1 of the documented fix is to retry, since the mapped APIError is retryable. If ZlibError keeps recurring, steps 2 and 3 tell you to suspect a proxy that re-compresses or truncates the response body, then bypass that proxy for the provider host and retry the identical message. Retry is step one because a single corrupted gzip stream can be a transient fluke. A ZlibError that keeps coming back is different: something is reliably damaging the compressed body. Middleboxes that inspect traffic often decompress, modify, and re-compress responses, or cut them short when they exceed a scanning limit, and a re-compressed or truncated gzip body will not inflate cleanly on the Atlas side. Bypassing the proxy for the provider host removes the rewrite and is the cleanest test. Stated plainly, the caveat is that Atlas cannot repair a body that arrived corrupted, so the fix has to happen on the network path. ## ZlibError vs MessageAbortedError in Atlas Atlas distinguishes ZlibError from MessageAbortedError deliberately, and they are 2 different outcomes. A FetchDecompressionError becomes a retryable APIError with code ZlibError, but if the request was aborted, Atlas maps it to MessageAbortedError instead. MessageAbortedError means you cancelled the request, and it is not a failure that needs fixing. Cancelling a generation tears down an in-flight compressed body, which at the byte level looks a lot like corruption. Atlas checks for the abort case first, so a request you cancelled surfaces as MessageAbortedError rather than as a misleading "Response decompression failed". If you see MessageAbortedError after hitting cancel, nothing is broken and there is nothing to repair. If you see ZlibError while you were sitting still and waiting for the answer, the body genuinely failed to inflate, and the proxy and truncation checks apply. Reading the metadata code before you start debugging saves the wasted trip. ## How to verify the Response decompression failed fix worked Verify the fix in Atlas by resending the exact message that failed and confirming 0 APIErrors arrive with the metadata code ZlibError. A response that renders fully, on the same provider and through the same network path minus the proxy, is proof that the gzip or deflate body now inflates cleanly. Repeat the original request rather than a simpler one, because a small response may compress into a body that survives a truncating proxy while a large one does not. Confirm three things after the retry: the assistant message completes, the metadata carries no ZlibError code, and the message is not "Response decompression failed". If ZlibError reappears the moment you route back through the proxy, you have identified the cause conclusively and the fix belongs with whoever administers that proxy. ## FAQ ### What does ZlibError mean in Atlas ZlibError is the metadata code Atlas attaches when a FetchDecompressionError is raised, meaning the gzip/deflate response body could not be inflated. Atlas maps it to a retryable APIError with the message "Response decompression failed". ### Is Response decompression failed retryable in Atlas Yes. Atlas maps the FetchDecompressionError to a retryable APIError, so retrying is the documented first step. A ZlibError that recurs on every retry usually means a proxy is re-compressing or truncating the body. ### Can a proxy cause Response decompression failed in Atlas Yes. A proxy that re-compresses or truncates the response body will produce a gzip/deflate stream that Atlas cannot inflate. Bypass the proxy for the provider host and retry to confirm. ### Why did Atlas give me MessageAbortedError instead of ZlibError Atlas maps an aborted request to MessageAbortedError rather than to a decompression APIError. If you cancelled the request yourself, MessageAbortedError is expected and is not a failure. ### Does Response decompression failed mean the model failed No. "Response decompression failed" means the response body arrived but could not be inflated. The model produced output. The failure is in the gzip/deflate transport layer, not in the model. ### How do I confirm the ZlibError is gone in Atlas Resend the exact message that failed and check that the reply completes with no ZlibError code in the APIError metadata. Use the original large request, not a small one, since small bodies can slip past a truncating proxy. --- Canonical HTML: https://runatlas.sh/resources/troubleshooting/response-decompression-failed Source of truth: aeo_pages row `/resources/troubleshooting/response-decompression-failed` (segment: Troubleshooting) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.