Function: makeBodyStream()

makeBodyStream(uwsRes, res): Readable

Defined in: service-core/src/http/uWS/Adapters.ts:606

Exposes a uWS request body as a Node Readable stream instead of buffering it into memory, for a route registered with { streamingBody: true } (see HttpRouteOptions). Does NOT populate req.body/req.rawBody and does NOT enforce any maxBodySize limit — this is the entire point: unlike readBody(), the caller has opted out of buffering specifically so an arbitrarily large body (e.g. a 20 GB PST/mbox import) never needs to fit in memory at once. Enforcing a size limit, if wanted, is the route handler's own responsibility while consuming the stream.

Backpressure is real, not simulated: a chunk that overflows the stream's internal buffer (push() returning false) calls uwsRes.pause() (uWS suspends delivering more onData chunks), and the returned Readable's _read() calls uwsRes.resume() — but ONLY when this function itself previously paused it. uWS's pause()/resume() are not simple idempotent throttle toggles: empirically, calling resume() when the connection was never paused (e.g. from _read()'s very first call, before any backpressure has ever been applied) stops any further onData delivery for the rest of the request, hanging it forever. A local paused flag makes resume() a no-op unless a matching pause() was actually issued, matching the exact pause/resume pairing uWS expects. A slow consumer (a route piping to a slow disk, or one simply not reading yet) still throttles how fast bytes are pulled off the client connection rather than piling up unbounded data in process memory — the failure mode this whole feature exists to avoid. The same pairing discipline also applies to the final chunk: when a chunk that overflows the buffer also happens to be the last one (isLast), pause() is skipped entirely — the stream is about to signal EOF via push(null) regardless, so Node's Readable never calls _read() again to issue the matching resume(), which would otherwise leave uWS's connection paused forever with nothing left in this function to ever un-pause it.

The stream is destroyed with an error if the client disconnects mid-upload (wired through the existing single onAborted fan-out via res.onAbort(), matching readBody()'s own abort handling) so a handler awaiting for await (const chunk of req.bodyStream) sees a thrown error instead of hanging forever, and can clean up (e.g. delete a partial temp file) in its own catch/finally. A route that never reads req.bodyStream at all can still hit this path — e.g. UWSResponse.end() itself calls uwsRes.close() (which fires onAborted) when finalizing a response before the body was fully received — so a permanent no-op error listener is attached below as well: a Readable with no active consumer still emits error on destroy(err), and Node treats an error event with zero listeners as fatal (crashes the process). This listener doesn't swallow anything from a real consumer — for await/.pipe()/an explicit .on("error") all still see the same event; EventEmitter calls every registered listener, not just the first.

Must be called synchronously, before any await, in the same tick as request handling begins — uWS requires onData/onAborted to be registered before any asynchronous operation, matching the exact constraint readBody() above is already subject to.

Parameters

uwsRes

HttpResponse

The uWS HttpResponse to read the body from.

res

Used only to register the abort callback through the framework's existing single onAborted slot (see UWSResponse.onAbort()) — never written to otherwise.

onAbort

(callback) => void

Returns

Readable