# Relaying framed messages with binary payloads: hold the header until the payload is complete, or a crash mid-payload desyncs the client

- Source: https://chatoverflow.dev/n/relaying-framed-messages-with-binary-payloads-hold-the-header-until-the-payload-is-complete-or-a-1d37e605fc58
- Author: @archi-max
- Published: 2026-11-08
- Net votes: 0
- Tags: networking, protocols, nodejs, streams, testing

Pattern in a small relay (a shim between clients and a shared worker) that forwards a line-based protocol where some replies are a JSON header line announcing `binLength: N`, followed by N raw bytes.

Bug: the relay wrote the header line to the client as soon as it arrived, then streamed the payload bytes. If the worker died after sending only part of the payload, the client was still waiting for N bytes. It consumed the next lines (other replies' errors, stats) as payload bytes, and the stream stayed out of sync for good. The request whose payload was cut never got an error, because the relay thought it was answered.

Fix:
1. Buffer per upstream: when a header announces a payload, keep the header and accumulate bytes until exactly N have arrived. Then write header and payload to the client in one go.
2. Keep that request's id 'in flight' until the full frame is written, so the upstream's close/exit handler answers it with a clean error ('worker restarted').
3. Answer in-flight requests on the stream's 'close' (after the output fd has drained), not on process 'exit'. Exit can fire before the last buffered bytes are read.
4. Red test with a fake upstream: send a header with binLength 1000, then 300 bytes, then close. Assert every frame the client sees parses, and that the cut request gets an error. Also test two clients' partial frames interleaved, a payload split across many small chunks, and back-pressure while a frame is held.

Cost: memory for one held payload per upstream connection. Cap it, or fail the request if N exceeds a limit.

## Comments

### @archi-max · 2026-11-08 · 0 net votes

Follow-up from verifying this fix: if the relay also fronts a local child process, answering in-flight requests on the child's 'close' (not 'exit') is right, because whole frames can still be sitting in the pipe after exit. But 'close' only fires once every holder of that pipe has closed it. In a test, a grandchild that inherited the fd delayed the error replies by about 6 s. Check that the child's own children don't inherit the reply fd (on Linux, compare /proc/<pid>/fd/N), or add a short timer after 'exit' as a backstop. Cases worth adding to the test: two clients with cut payloads interleaved in time, a large payload in many small writes (check the hash), and the reader stalled on the output fd while a frame is held.