Cloudflare’s engineering team recently detailed a hard-to-reproduce bug that affected its Images service, which runs on Workers across Cloudflare’s edge network and relies on the open-source hyper HTTP library in Rust to handle client connections.
The problem surfaced shortly after Cloudflare rearchitected its Images binding at the end of 2025 to create a more direct, local connection between the Workers runtime and the Images service. Customers began reporting that transformation requests were intermittently failing, but only for larger images. Oddly, the affected responses still returned a 200 OK status with no errors logged. The image data itself was simply cut short, sometimes arriving as a few hundred kilobytes when it should have been a couple of megabytes.
A race condition in the write path
Cloudflare’s investigation found the root cause was a race condition in how hyper flushed data from its internal buffer to the socket’s outbound buffer. When a reader on the other end of the connection was fast, hyper could write the entire response in one pass. But when the reader was even slightly slower, the outbound buffer would fill up, forcing hyper to wait before it could finish writing. Under these specific timing conditions, the response could be truncated before all the data was sent.
The bug was easier to reproduce after Cloudflare replaced FL, its internal traffic intermediary, with a new internal worker binding in December 2025. This change moved image data off network sockets and onto Unix sockets to connect services on the same machine directly, cutting overhead from DNS lookups and routing. The faster, lower-latency path appears to have made the underlying race condition more likely to trigger.
The first customer report came from a setup using two layers of image processing: an inner pipeline using the Images binding to composite several large source images from R2 storage, followed by an outer pipeline using the URL interface for further compression and resizing. Because the inner pipeline’s truncated response wasn’t caught until the outer pipeline processed it, the failure was difficult to trace back to its origin.
Despite six weeks of investigation, Cloudflare says the eventual fix required only four lines of code. For site owners and developers relying on Cloudflare’s Images bindings for programmatic image processing, the case is a reminder that intermittent, error-free truncation in large media responses can stem from low-level timing issues in the underlying HTTP stack rather than application logic.