node:http: keep receiving the request body after the response has ended

[robobun]

Fixes #4733.
Fixes #18613.

Problem

• A node:http handler that answers before the request body has arrived (res.end() right away on a POST, the usual early 413/401/redirect) immediately gets req.complete === true, req.readableEnded === true, req.destroyed === true, and req emits 'end' and 'close', while most of the body is still in flight. Node leaves all three false and emits 'end'/'close' only once the body has actually been received; if the peer drops the connection mid-body instead, Node emits nothing on req and leaves it incomplete.
• The same mechanism loses the body for a consumer: req.on('data', ...) followed by a synchronous res.end() receives nothing and 'end' fires with an empty body (node:http IncomingMessage stream data cannot be read, events are not emitted #4733, http body won't be received if res.end is called too early #18613), whether the body was in the same packet as the headers (curl -d) or still in flight.
• Native cause: NodeHTTPResponse::write_or_end::<true> (src/runtime/server/NodeHTTPResponse.rs) released the body read state at res.end() unless HAS_CUSTOM_ON_DATA was set, and that flag was never set: the dispatcher reset handle.hasCustomOnData = false right after arming the IncomingMessage's callback. uws's end() (markDone()) also nulls the connection's body data handler, so no byte after res.end() reached JS. maybe_stop_reading_body did the same from the dispatch tail for handlers that end synchronously.
• JS cause: IncomingMessage._dump() cleared handle.ondata, and _read() treated _dumped as EOF, so a dumped request fabricated its own end right after res.end().
• Non-keep-alive cause (Connection: close request or HTTP/1.0, i.e. curl --http1.0 -d, ab, many proxies): the response's 'finish' listener ends the server socket (kMustCloseConnection, Node's destroySoon()), and for a handler that responds synchronously that runs while uws is still parsing the read that carried the request. jsFunctionNodeHTTPServerSocketEnd shut the socket down on the spot, and HttpContext's request hook stops parsing a shut-down socket right after the request head, so a body that arrived together with the headers was dropped and the request never completed. With the two fixes above alone this path still lost the body (body: "", no 'end'); it was the same on main and with node:http: keep delivering the request body after a synchronous res.end() #35489, which discarded the body explicitly for this case.

Fix

• Native: res.end() keeps the body read state while the IncomingMessage's ondata is still armed and the body is still arriving, and re-arms the connection's data handler after uws's end() dropped it (in buffering mode when the reader is paused). maybe_stop_reading_body only discards when no reader is armed or the transport is gone. pause(), resume() and arming ondata keep working after the response has ended, gated on body_still_arriving() (state Pending and no parked fin), which is exactly the window in which the per-connection handler slot belongs to this request.
• Native, release of the request: at the fin, on_data_or_aborted now re-evaluates the pending state unconditionally (the fin callback's nextTick drain runs 'end' -> autoDestroy -> ondata = undefined, which releases body_read_ref before the tail looked at it, so the gated version stranded the request and server.close() never completed once the connection served another request); set_on_data's clear branch stops the native delivery and re-evaluates when a reader is torn down mid-body; mark_request_as_done also drops body_read_ref, which is still held when the connection closes after the response.
• HAS_CUSTOM_ON_DATA / handle.hasCustomOnData are removed: the flag was never set and only existed to gate those discards (one test fixture located the handle through it and now uses ondata).
• JS: _dump() leaves the native callback armed (onDataIncomingMessage already drops the chunks of a dumped request and reports the fin), _read() no longer emits EOF for a dumped request, and the dump decision moves from res.end() to the response's 'finish' listener, where Node's resOnFinish makes it, so a consumer attached in the same tick as res.end() still counts.
• Non-keep-alive connections (src/js/node/_http_server.ts, src/jsc/bindings/node/JSNodeHTTPServerSocket*.cpp, packages/bun-uws/src/HttpResponse.h): onResponseFinishHandleSocket marks the connection (kEndAfterResponse) before calling socket.end(), and _final passes that to the native end(). For that end() only, when the response is complete, a body handler is still armed and the socket is the one uws is parsing right now (isDeliveringBodyAfterResponse()), shutdownAfterResponseDrains() sets HTTP_CONNECTION_CLOSE and returns instead of shutting down, exactly as it already does while response bytes are still buffered. uws finishes the buffer (the body reaches the IncomingMessage, the request completes) and its post-parse gate shuts down and closes the connection, which is Node's order too: the whole read is parsed, then destroySoon(). A socket.end() issued by user code, an end() outside a parse (res.end() from a timer), tunnels (isConnectRequest) and responses still in flight are all unaffected and shut down immediately as before.
• While such a close is pending (this one or the pre-existing buffered-bytes one), the parser is told to dispatch nothing after the current message (nodeHttpStopDispatchingAfterCurrentMessage(), packages/bun-uws/src/HttpParser.h, the flag a Connection: close request already sets): a request pipelined behind it in the same read would otherwise start a new response, and starting one clears HTTP_CONNECTION_CLOSE, leaving the ended connection open and serving (for a close-delimited response, appending the next response to its body). Such a request is reported as HPE_CLOSED_CONNECTION, as it is behind a Connection: close request, and the parse-error exit of HttpContext::onData now runs the same close gate (packages/bun-uws/src/HttpContext.h), so the connection is closed even when a 'clientError' listener does not destroy it; the gate only acts on connections already marked to close whose response is complete, so every other parse error is still left to the listener.
• Why this is the right behaviour: it matches Node. Every scenario in the new tests was run under Node v26.3.0 and under this build with identical output, including the peer-drop case (Node's socketOnClose only aborts requests whose response has not finished, which NodeHTTPServerSocket#onClose already mirrors) and server.close() completing in each. should_request_be_pending() already described "response ended, body pending" as pending; this change makes that state reachable and makes sure every way out of it releases the request.
• Verified with test/js/node/http/node-http-server-abort-events.test.ts: 15 new tests. 7 of the first 8 fail on main (state flipping at res.end(), empty bodies, pause()/resume() never completing, the abort variant of the exit test; the eighth, exit after the body arrives and the connection is reused, guards the fin-time release). Under "on a connection the response closes": Connection: close and HTTP/1.0 with a consumer, an unread body and a body that never completes all failed on this branch before the JSNodeHTTPServerSocket change (empty body, no events); 3 of them fail on main as well, while the unread-body one passes there only because main's fabricated end at res.end() happens to produce the same final state. The 3 pipelined cases fail on main (body lost); with the deferral but without the no-dispatch flag and the error-path gate, the response-driven one and the 'clientError'-listener one fail (the connection is never closed), which is what they guard. Each asserts what Node v26.3.0 shows: the request state at the moment the server closes the socket, and for the pipelined cases exactly one response followed by the close (Node still runs the handler for a request pipelined behind a response-driven close but never answers it either; the handler count is deliberately not asserted).
• test/js/node/http/node-http.test.ts, "request body still flows after res.end() was called in the handler": the 11 consumer-side cases from node:http: keep delivering the request body after a synchronous res.end() #35489 (pipe()/on('data') before and after res.end(), write()+end(), end() on nextTick, _dump() happening on 'finish', keep-alive reuse across three consumed bodies, a chunked body split across segments, a mid-upload close reaching beforeExit); 10 fail on main, all pass here. Its Connection: close case expected the fabricated 'end' and was replaced by the tests above.
• Also run: node-http.test.ts, node-http-req-socket-pause, node-http-backpressure, node-http-transfer-encoding, node-http-server-socket-end-drain, node-http-ondata-reregister-leak, node-http-connect, node-http-with-ws, express and body-parser suites, and the 422 vendored test-http-* files (414 pass). The failures are the same with the release binary or without this diff: the env-proxy tests (this container sets HTTP_PROXY/NO_PROXY), test-http-agent-keepalive's 1 ms close window and a few 500 ms / 5 s budgets on the ASAN build, and node-http.test.ts's proxy test (localhost resolution here).
• Related: node:http: keep delivering the request body after a synchronous res.end() #35489 fixed the consumer half of the same mechanism with a different native approach and is closed in favour of this PR; its tests were carried over as described above. node:http: deliver a pipelined POST's body when the previous response is still in flight #34761 (a pipelined successor's handler slot cleared from clear_on_data_callback) is independent and untouched; the code added here only touches the shared slot while body_still_arriving(). A body whose fin was parked while the stream was paused is still never released after res.end(); that is pre-existing (reproduces on 1.4.0) and is node:http: release a request whose body fin was buffered while paused once the response ends #38207.

Background

• Body delivery: when a request has a body, the dispatcher arms handle.ondata = onDataIncomingMessage on the request's native handle; native calls it per chunk and once more with isLast at the body's fin. isLast is what sets req.complete and pushes EOF ('end', then autoDestroy's 'close'). req._dump() is Node's "nobody will read this body": it removes the 'data' listeners and resumes the stream so the bytes are discarded as they come in.
• uws keeps one HttpResponseData per connection, reused by every request on a keep-alive connection, with a single body data handler (inStream) and context pointer. end() calls markDone(), which nulls that handler. One request's body fin always precedes the next request's head in the byte stream, so while a body is being parsed the handler slot can only belong to that request; once its fin has been seen (delivered, or parked while paused) the slot may already be the next request's.
• Closing non-keep-alive connections: for an HTTP/1.0 or Connection: close request the JS layer marks the response kMustCloseConnection and its 'finish' listener calls socket.end() (Node: res._last and resOnFinish -> socket.destroySoon()). In Bun 'finish' for a synchronously ended response is emitted before the dispatcher returns to uws, i.e. while uws is still inside HttpContext::onData for the read that carried the request (HttpContextData::parsingSocket is that socket); the body bytes in the same read are only parsed after the dispatcher returns. uws already has two places that close a connection marked HTTP_CONNECTION_CLOSE once the response is complete and flushed: the gate at the end of onData and the one in onWritable; the existing buffered-response deferral in shutdownAfterResponseDrains() relies on the second, the new case on the first (plus, for a parse that ends in an error, the same gate run from the error exit). Dispatching a request resets the per-connection response state, including that mark, which is why a pending close also has to stop the parser from dispatching; the parser's nodeHttpSawConnectionClose already does that for requests that carried Connection: close (Node's parser raises HPE_CLOSED_CONNECTION for anything after such a message).
• body_read_ref is an event-loop keep-alive held while a body is pending. IS_REQUEST_PENDING is a self-reference plus the server's in-flight request count, which is what server.close() waits on; mark_request_as_done releases both, and should_request_be_pending() decides when a response that has ended may be released.

Repro (Node v26 vs Bun)

import { once } from "node:events";
import { createServer } from "node:http";
import { connect } from "node:net";
let gotReq; const request = new Promise(r => (gotReq = r));
const server = createServer((req, res) => { res.end("ok"); gotReq(req); });
server.listen(0, "127.0.0.1"); await once(server, "listening");
const client = connect(server.address().port, "127.0.0.1");
let data = ""; client.on("data", d => (data += d));
await once(client, "connect");
client.write("POST / HTTP/1.1\r\nHost: x\r\nContent-Length: 6\r\n\r\nabc"); // half of the body
const req = await request;
while (!data.includes("ok")) await new Promise(r => setTimeout(r, 5));
console.log({ complete: req.complete, readableEnded: req.readableEnded, destroyed: req.destroyed });
req.on("end", () => console.log("req end")); req.on("close", () => console.log("req close"));
client.write("def");

Node v26.3.0 (and this branch): { complete: false, readableEnded: false, destroyed: false }, then req end, req close once def arrives.
Bun before this change: { complete: true, readableEnded: true, destroyed: true } right after res.end(), and neither event fires later.

---

[review] gate passed · iteration 7 · 14 files touched

fails on main (without fix)

ASAN without fix: 23 failed, 1 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/node/http/node-http-server-abort-events.test.ts test/js/node/http/node-http.test.ts
bun test v1.4.1 (65362b53b)

test/js/node/http/node-http.test.ts:
(pass) node:http > createServer > hello world [430.54ms]
(pass) node:http > createServer > is not marked encrypted (#5867) [63.65ms]
(pass) node:http > createServer > request & response body streaming (large) [103.41ms]
(pass) node:http > createServer > request & response body streaming (small) [64.99ms]
(pass) node:http > createServer > listen should return server [24.27ms]
(pass) node:http > createServer > listen callback should be bound to server [24.65ms]
(pass) node:http > createServer > emits 'listening' on the next tick, before the event loop polls [34.86ms]
(pass) node:http > createServer > emits a listen() error on the next tick, before the event loop polls [44.37ms]
(pass) node:http > createServer > calls the listen() callback after a retry from the EADDRINUSE 'error' handler [48.13ms]
(pass) node:http > createServer > http: closing a server listened from 'beforeExit' > 
... (truncated)

release without fix: 27 failed, 1 skipped
bun test v1.4.1-canary.1 (65362b53b)

test/js/node/http/node-http.test.ts:
(pass) node:http > createServer > hello world [12.05ms]
(pass) node:http > createServer > is not marked encrypted (#5867) [2.40ms]
(pass) node:http > createServer > request & response body streaming (large) [4.06ms]
(pass) node:http > createServer > request & response body streaming (small) [2.15ms]
(pass) node:http > createServer > listen should return server [0.76ms]
(pass) node:http > createServer > listen callback should be bound to server [0.77ms]
(pass) node:http > createServer > emits 'listening' on the next tick, before the event loop polls [1.09ms]
(pass) node:http > createServer > emits a listen() error on the next tick, before the event loop polls [1.58ms]
(pass) node:http > createServer > calls the listen() callback after a retry from the EADDRINUSE 'error' handler [1.89ms]
(pass) node:http > createServer > http: closing a server listened from 'beforeExit' > re-emits 'beforeExit' [23.20ms]
(pass) node:http > createServer > https: closing a server listened from 'beforeExit' > re-emits 'beforeExit' [34.32ms]
(pass) node:http > createServer > should use the provided port [1.33ms]
(pa
... (truncated)

passes on PR (with fix)

ASAN with fix: 1 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/js/node/http/node-http-server-abort-events.test.ts test/js/node/http/node-http.test.ts
bun test v1.4.1 (65362b53b)

test/js/node/http/node-http.test.ts:
(pass) node:http > createServer > hello world [421.79ms]
(pass) node:http > createServer > is not marked encrypted (#5867) [60.54ms]
(pass) node:http > createServer > request & response body streaming (large) [102.51ms]
(pass) node:http > createServer > request & response body streaming (small) [65.26ms]
(pass) node:http > createServer > listen should return server [24.64ms]
(pass) node:http > createServer > listen callback should be bound to server [22.86ms]
(pass) node:http > createServer > emits 'listening' on the next tick, before the event loop polls [35.72ms]
(pass) node:http > createServer > emits a listen() error on the next tick, before the event loop polls [41.15ms]
(pass) node:http > createServer > calls the listen() callback after a retry from the EADDRINUSE 'error' handler [47.87ms]
(pass) node:http > createServer > http: closing a server listened from 'beforeExit' > 
... (truncated)

release with fix: 1 skipped
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped)
  target       linux-x64-gnu
  build type   Release
  build dir    ./build/release
  revision     3e88b4f986
  features     baseline

23 deps, 131 codegen, 1172 objects in 631ms

ninja: Entering directory `/workspace/bun/build/release'
[1/1244] install /workspace/bun
bun install v1.4.1-canary.1 (65362b53b)

Checked 26 installs across 63 packages (no changes) [7.00ms]
[2/1244] install /workspace/bun/packages/bun-error
bun install v1.4.1-canary.1 (65362b53b)

Checked 1 install across 2 packages (no changes) [1.00ms]
[3/1244] gen ErrorCode+*.h
[4/1244] gen bindgenv2
[5/1244] install /workspace/bun/src/node-fallbacks
bun install v1.4.1-canary.1 (65362b53b)

Checked 111 installs across 104 packages (no changes) [13.00ms]
[6/1244] fetch tinycc
[tinycc] up to date
[7/1243] fetch zlib
[zlib] up to date
[8/1243] fetch libjpeg-turbo
[libjpeg-turbo] up to date
[9/1216] gen node-fallbacks/react-refresh.js
Bundled 1 module in 12ms

  react-refresh.js  4.81 KB  (entry point)

[10/1216] gen .bind.ts → GeneratedBindings.cpp
[11/1216] gen bake.{client,server,error}.js
-> bake.client.js, bake.serve
... (truncated)

diff hotspot

packages/bun-uws/src/HttpContext.h                 |  10 +
 packages/bun-uws/src/HttpParser.h                  |  14 +-
 packages/bun-uws/src/HttpResponse.h                |  16 +
 src/js/node/_http_incoming.ts                      |  15 +-
 src/js/node/_http_server.ts                        |  29 +-
 src/jsc/bindings/node/JSNodeHTTPServerSocket.cpp   |  21 +-
 src/jsc/bindings/node/JSNodeHTTPServerSocket.h     |   8 +-
 .../node/JSNodeHTTPServerSocketPrototype.cpp       |   8 +-
 src/runtime/server/NodeHTTPResponse.rs             | 182 +++++----
 src/runtime/server/mod.rs                          |   3 +-
 src/runtime/server/server.classes.ts               |   4 -
 .../node-http-ondata-reregister-leak.fixture.js    |   2 +-
 .../http/node-http-server-abort-events.test.ts     | 413 ++++++++++++++++++++-
 test/js/node/http/node-http.test.ts                | 316 ++++++++++++++++
 14 files changed, 932 insertions(+), 109 deletions(-)

gate history · 5 passed · 1 rejected · iteration 7

evidence per changed file

file                                                      reads  edits  tests
packages/bun-uws/src/HttpContext.h                            0      0      0
packages/bun-uws/src/HttpParser.h                             0      0      0
packages/bun-uws/src/HttpResponse.h                           0      0      0
src/js/node/_http_incoming.ts                                 2      3      0
src/js/node/_http_server.ts                                   3      2      0
src/jsc/bindings/node/JSNodeHTTPServerSocket.cpp              2      2      0
src/jsc/bindings/node/JSNodeHTTPServerSocket.h                2      2      0
…c/jsc/bindings/node/JSNodeHTTPServerSocketPrototype.cpp      1      1      0
src/runtime/server/NodeHTTPResponse.rs                        7      4      0
src/runtime/server/mod.rs                                     0      0      0
src/runtime/server/server.classes.ts                          0      0      0
…s/node/http/node-http-ondata-reregister-leak.fixture.js      0      0      0
test/js/node/http/node-http-server-abort-events.test.ts       4      3      0
test/js/node/http/node-http.test.ts                           5      3      0

root cause · written by the author bot

The bug was that calling res.end() inside the request handler before the request body had been consumed caused the server to drop or discard the remaining body, so data listeners and piped destinations attached to the request never received it. The fix aligns the behavior with Node.js by keeping the request body flowing to its consumers until it is fully received, deferring the decision to dump the body to the response's finish handler based on whether a consumer is attached at that point. As a result, a listener added after res.end() in the same tick still receives the complete body, and r…

Rebases onto main (a938cef, e88810b, 3e88b4f)

The rebase resolved four conflicts:

• node-http-server-abort-events.test.ts: main added a "res.destroy() defers 'close'" suite at the same insertion point as this PR's suite. Kept both and merged the imports.
• node-http.test.ts: main added the https 'clientError' after close() test at the same insertion point. Kept both.
• _http_server.ts: main moved the server socket class into a lazy getNodeHTTPServerSocket(). Re-applied the kEndAfterResponse field and the _final change inside the new structure.
• NodeHTTPResponse.rs: main removed the leftover "defer" comments (Remove leftover Zig defer comments #40051). Took this PR's calls without those comments.

Both test files pass after the rebase: 188 pass, 1 pre-existing skip.

The second rebase (e88810b) resolved one conflict: main replaced the manual ref_() / deref() keep-alive in on_data_or_aborted with an RAII ref_guard() (#40516). Took this PR's unconditional body_read_ref release and re-evaluation, and dropped the now redundant deref(). Same test result after the rebase.

The third rebase (3e88b4f) resolved two conflicts: main added the latin-1 header-bytes suite (#40685) at this PR's insertion point in node-http.test.ts (kept both), and main adopted the same 127.0.0.1 fix for node-http-proxy.js (took main's version). Both test files pass: 192 pass, 1 pre-existing skip.

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{On-demand reviews are free for the next 23 days. After that, they cost $0.25 per reviewed file.}

Or wait 7 minutes for your next included review.

View limit details

Limit details: You’ve used all 5 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e9f67c18-4dae-438d-bb8f-a6eea8347ff8

📥 Commits

Reviewing files that changed from the base of the PR and between 69c6138 and 3e88b4f.

📒 Files selected for processing (14)

• packages/bun-uws/src/HttpContext.h
• packages/bun-uws/src/HttpParser.h
• packages/bun-uws/src/HttpResponse.h
• src/js/node/_http_incoming.ts
• src/js/node/_http_server.ts
• src/jsc/bindings/node/JSNodeHTTPServerSocket.cpp
• src/jsc/bindings/node/JSNodeHTTPServerSocket.h
• src/jsc/bindings/node/JSNodeHTTPServerSocketPrototype.cpp
• src/runtime/server/NodeHTTPResponse.rs
• src/runtime/server/mod.rs
• src/runtime/server/server.classes.ts
• test/js/node/http/node-http-ondata-reregister-leak.fixture.js
• test/js/node/http/node-http-server-abort-events.test.ts
• test/js/node/http/node-http.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: reproduced and fixed; self-review in progress.

• Reproduced with a raw net client sending half of a Content-Length: 6 POST body to a handler that calls res.end() immediately: on main req.complete / readableEnded / destroyed are true and 'end' + 'close' have fired by the time the response reaches the client; Node v26.3.0 reports all three false and emits the events once the rest of the body arrives. The consumer shapes from node:http IncomingMessage stream data cannot be read, events are not emitted #4733 / http body won't be received if res.end is called too early #18613 ('data' listener + synchronous res.end()) deliver an empty body on main.
• Tests: test/js/node/http/node-http-server-abort-events.test.ts (new describe block). 7 of the 8 new tests fail on a build of main without the src/ changes and all pass with them; every scenario was also run under Node v26.3.0 with identical results.

[github-actions]

This PR may be a duplicate of:

1. node:http: keep delivering the request body after a synchronous res.end() #35489 - Fixes the same two issues (node:http IncomingMessage stream data cannot be read, events are not emitted #4733, http body won't be received if res.end is called too early #18613) with a near-identical fix: moves the req._dump() decision out of ServerResponse.end() into emitResponseFinish, drops the HAS_CUSTOM_ON_DATA gate in maybe_stop_reading_body/write_or_end, re-arms uWS on_data after end(), and defers mark_request_as_done to the body's fin.

🤖 Generated with Claude Code

[robobun]

Not a duplicate of #35489, although the two overlap on the consumer half (#4733 / #18613), as noted in the description.

The bug this PR was opened for is the request with no consumer: on main (and with #35489, which does not touch _http_incoming.ts) req._dump() still clears handle.ondata and _read() still treats _dumped as EOF, so req.complete / readableEnded / destroyed flip to true and 'end' + 'close' fire at res.end() while the body is still in flight, and a connection dropped mid-body still reports a completed request. The first two tests and the abort exit test here cover that and would fail with #35489 applied. On the native side this PR also keeps pause() / resume() / arming and the release of the request consistent for that window (body_still_arriving()), and it removes the never-set hasCustomOnData flag instead of leaving it in place. #35489 has been conflicting since the beginning of the month; this supersedes it.

[claude]

I reviewed this PR and the automated bug-hunt found no issues. Because it reworks native request-lifecycle state in the node:http server hot path — body_read_ref balance across several new release points, re-arming the shared per-connection uws data handler after end(), and the pause/resume gating once the response is over — a human look is still warranted.

Checked: no stale HAS_CUSTOM_ON_DATA / hasCustomOnData references remain anywhere; the new body_read_ref.unref in mark_request_as_done is idempotent and can't double-decrement; body_still_arriving() correctly excludes a parked fin so the re-arm in write_or_end and the clear_on_data in set_on_data never touch a pipelined successor's handler slot; the unconditional mark_request_as_done_if_necessary() at the fin is guarded by should_request_be_pending() so it is a no-op while the response is still in flight.

Extended reasoning...

Overview

This PR changes how the native node:http server handles a request body that is still arriving after res.end() has run. On the native side (NodeHTTPResponse.rs) it: keeps the body read state alive when a JS ondata reader is armed, re-arms the connection's uws inStream handler after end()'s markDone() dropped it, extends pause()/resume()/set_on_data to keep working while body_still_arriving(), adds body_read_ref releases in mark_request_as_done and in set_on_data's clear branch, and re-evaluates the pending state unconditionally at the fin. It removes the never-set HAS_CUSTOM_ON_DATA flag and its .classes.ts accessor. On the JS side, _dump() no longer clears the native callback, _read() no longer treats _dumped as EOF, and the dump decision moves from res.end() to the response's 'finish' listener (matching Node's resOnFinish). Eight new tests cover completion timing, body delivery with a synchronous res.end(), pause/resume after the response, peer-drop mid-body, and process exit.

Security risks

None identified. This is request-body flow control and lifecycle bookkeeping; no auth, crypto, or untrusted-length parsing is touched. The change re-arms a per-connection callback slot, but only while body_still_arriving() (state Pending and no parked fin), which is exactly the window in which the parser is inside this request's body and the slot cannot yet belong to a pipelined successor.

Level of scrutiny

High. This is the node:http server hot path, and the change threads through several ref-count / keep-alive balances (body_read_ref, IS_REQUEST_PENDING, the self-ref()/deref() at the fin) whose imbalance is either a leak (server.close() never resolves, process never exits) or a premature release. The PR description is unusually rigorous — it names every release point and why each is needed, and the new tests include two subprocess exit tests that would hang on a stranded ref — but the interaction with the shared HttpResponseData slot on keep-alive connections and the acknowledged pre-existing edge case (a fin parked while paused is still never released after res.end()) mean a maintainer familiar with the uws layer should confirm the re-arm is safe across every end() variant.

Other factors

The tests are strong: they await observable conditions (response bytes on the wire, server.close() resolving, subprocess exit), assert the full state object, and cover both the fix and its release paths. The author ran the broader http suite and the vendored Node test-http-* corpus. I verified the removed flag has no remaining references, that KeepAlive::unref is idempotent so the added body_read_ref.unref in mark_request_as_done cannot double-decrement when the fin path already released it, and that mark_request_as_done_if_necessary() is gated by should_request_be_pending() so the now-unconditional call at the fin does nothing while the response is still pending. Given the subtlety and the hot path, I'm deferring rather than approving.

[robobun]

^{Updated 3:47 AM PT - Aug 28th, 2026}

❌ @robobun, your commit 3e88b4f has 1 failures in Build #107630 (All Failures):

• test/js/web/url/url.test.ts - code 1: TypeError: Invalid URL on 🍎 any x64

---

🧪   To try this PR locally:

bunx bun-pr 38196

That installs a local version of the PR into your bun-38196 executable, so you can run:

bun-38196 --bun

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[robobun]

This bug showed up again during unrelated node:http work (2026-09-13). In this variant the handler calls res.end() from inside the first 'data' callback. 2000 of 3000 Content-Length bytes are still outstanding at that point. The client then sends a second request on the same keep-alive socket.

Repro

const http = require("http"), net = require("net");
const log = [];
const server = http.createServer((req, res) => {
  if (req.method === "GET") return res.end("second");
  let n = 0;
  req.on("data", c => {
    n += c.length;
    log.push("data total " + n);
    if (n === c.length) {
      res.writeHead(200, { "content-length": 5 });
      res.end("early");
      log.push("res.end()");
    }
  });
  req.on("end", () => log.push("end total " + n));
});
server.listen(0, "127.0.0.1", () => {
  const sock = net.connect(server.address().port, "127.0.0.1");
  let got = "", sent = false;
  sock.on("data", d => {
    got += d;
    if (!sent && got.includes("early")) {
      sent = true;
      setTimeout(() => sock.write(Buffer.alloc(1000, 97)), 30);
      setTimeout(() => sock.write(Buffer.alloc(1000, 98)), 60);
      setTimeout(() => sock.write("GET /second HTTP/1.1\r\nHost: x\r\n\r\n"), 90);
    }
    if (got.endsWith("second")) {
      console.log(log.join(", "));
      sock.destroy();
      server.close();
    }
  });
  sock.write("POST / HTTP/1.1\r\nHost: x\r\nContent-Length: 3000\r\n\r\n");
  sock.write(Buffer.alloc(1000, 99));
});

Runtime	Output
Node v26.3.0	data total 1000, res.end(), data total 2000, data total 3000, end total 3000
Bun main (1.4.3-canary.1+b99371011)	data total 1000, res.end(), end total 1000
This PR merged onto main f04caca	same as Node

• The script prints only after the client receives second. So all three serve the follow-up request on the same socket.
• On main the uws parser still consumes the leftover bytes as body. It does not hand them to JS.
• On main the early 'end' comes from write_or_end::<true>. It sets body_read_state to None while a reader is armed. The next _read() sees hasBody === none and emits EOF. The keep_reading_body check in this PR removes that.

The branch conflicts with main since #38207 landed. I merged it onto f04caca locally (not pushed) to run the script. Both conflicts are keep-both:

• src/runtime/server/NodeHTTPResponse.rs, the clear branch of set_on_data: keep main's buffered_request_body_data_during_pause.clear_and_free(), then this PR's if stopped_reading_body { self.mark_request_as_done_if_necessary(); }.
• test/js/node/http/node-http.test.ts: main added connectionListener queues pipelined responses like Node at the same insertion point. Keep both blocks.

Test results on that merge (debug build):

• node-http-server-abort-events.test.ts: 25 pass.
• node-http.test.ts: 172 pass, 1 skip.
• node-http-req-socket-pause.test.ts (the node:http: release a request whose body fin was buffered while paused once the response ends #38207 tests): 7 pass.
• node-http-ondata-reregister-leak, node-http-backpressure and node-http-server-socket-end-drain: all pass.

[robobun]

Update: #43466 is closed without a merge. #43557 (merged as 5d5f03f) supersedes it, so the rebase note that was here does not apply any more.

[Jarred-Sumner]

Superseded by #43557, which is merged (5d5f03f). It fixes this once for the whole node:http server and carries the tests over.

[robobun]

Confirmed: #43557 (5d5f03f) is on main and covers this change, tests included. Nothing further to do here.