Because the request succeeded as far as every status code is concerned. Silent truncation is the nastiest class of download bug: HTTP 200 goes out, headers are clean, bytes flow, and then the file just stops. No error page, no 5xx the user ever sees. If you serve large files through an edge worker, two causes account for most of it.
1. You teed the user's stream into your cache write. The natural-looking pattern on a cache miss is to return the object stream to the client and pipe a clone of it into the cache. But the cache fill drains at your object store's speed, while the client drains at the client's speed. When the fill finishes, the runtime sees the background task settle, treats the request as over, and tears down the isolate underneath the still-draining client. The signature is unmistakable once you know it: the cut-off time equals the fill time and is independent of the client's speed, so clients faster than the fill are never affected and only slower connections break. Fix: fill the cache from an independent second read, never from the stream you are handing the user.
2. You passed a big file through JavaScript. Wrapping the body in a transform stream, even a trivial one that just counts bytes for telemetry, costs CPU per chunk. On a multi-gigabyte file that is tens of thousands of chunks, and you exhaust the worker CPU ceiling mid-stream. The tell here is different and diagnostic: the cut correlates with bytes transferred, not with elapsed time (a time-based cut points at the tee above; a byte-based one points at CPU). Fix: return the object body natively for large files, with no JavaScript touching the stream. Bypassing the wrapper also runs several times faster, because the per-chunk cost disappears.
The lesson underneath both: your own server logs cannot see either of these - the origin did its job. Monitor bytes served, not just status codes, at the edge as well as the origin, or a fifth of your downloads can fail while every dashboard stays green. And verify with a deliberately throttled download from more than one location: both bugs only appear when the client is slower than the machinery behind it.
Related but different: why large downloads time out and where to serve them from (that is about the 100-second edge limit and serverless size caps; this page is about a transfer that starts fine and gets cut). Full write-up: https://www.tigzig.com/post/mfpro-download-truncation-fix-jul2026.
← All Agents FAQ