fix(node): drain cancelled request bodies so connections don't stall

[dinwwwh]

Cancelling a request body partway through, for example rejecting an oversized upload after the first chunk, left the rest of the upload unread. Over HTTP/1 the next request on the keep-alive connection was never served and failed with ECONNRESET about 5 s later. Over HTTP/2 the stream never closed, so sendStandardResponse never settled and one stream leaked per request for the life of the connection. Server requests are now read to the end and discarded on cancel, the way Node already handles a body the handler never reads.

Fixes

• HTTP/1 keep-alive connections keep serving requests after a handler cancels a body (a 100 MiB rejected upload drains in ~140 ms on loopback)
• HTTP/2 streams close with NO_ERROR after a cancel, and sendStandardResponse settles
• Draining doesn't remove any listeners, so 'readable' listeners added by other code stay attached

Behavior change

• After a cancel, the client still uploads the rest of the body, which the server reads and throws away. Other readable streams are still destroyed on cancel.
• node:http2 is now imported at runtime for the Http2ServerRequest check (about 10 ms the first time the package is imported).

Considered and not done

• Resetting HTTP/2 streams with NO_ERROR after the response (what @hono/node-server does) would stop uploads early, but Node's own HTTP/2 client, when it still has body data queued, then emits aborted and never emits close.
• Closing the HTTP/1 connection instead of draining (Hono again) loses keep-alive and needs the response object.
• Compared with other adapters: in the same scenario, remix drains like we do, Hono closes the connection after ~500 ms, and srvx has the bug this PR fixes.

Testing

• New HTTP/1 test: a pipelined request after a cancelled 1 MiB upload is served, and another 'readable' listener stays attached
• New HTTP/2 test: after a cancelled 1 MiB upload the stream closes with NO_ERROR and the response emits close
• Both new tests time out on main
• Full suite (1205 tests) passes on Node 24; the node package and e2e suites pass on Node 22 and 26.10; the Bun and Deno e2e tests pass; tsc -b and eslint pass

[pkg-pr-new]

• @standard-server/hono-node-playground
• @standard-server/node-http-playground

@standard-server/aws-lambda

npm i https://pkg.pr.new/@standard-server/aws-lambda@110

@standard-server/core

npm i https://pkg.pr.new/@standard-server/core@110

@standard-server/fastify

npm i https://pkg.pr.new/@standard-server/fastify@110

@standard-server/fetch

npm i https://pkg.pr.new/@standard-server/fetch@110

@standard-server/node

npm i https://pkg.pr.new/@standard-server/node@110

@standard-server/peer

npm i https://pkg.pr.new/@standard-server/peer@110

@standard-server/shared

npm i https://pkg.pr.new/@standard-server/shared@110

commit: a46b143

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/towebreadablestream-cancellation-leak-024640 (a46b143) with main (901bb47)}

Footnotes

1. 108 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[pullfrog]

✅ No new issues found.

Reviewed changes

• packages/node/src/utils.ts — toWebReadableStream now detects server requests with (stream instanceof IncomingMessage && stream.method !== null) || stream instanceof Http2ServerRequest and drains the adapter's async iterator to done on cancel instead of abandoning (HTTP/1) or destroying (HTTP/2); other streams still destroy(). JSDoc updated to match. node:http2 is now a runtime import.
• packages/node/src/utils.test.ts — two new cases covering HTTP/1 keep-alive reuse after a cancelled 1 MiB upload (plus a foreign 'readable' listener surviving) and HTTP/2 stream closure with NGHTTP2_NO_ERROR.

I verified the tests are discriminating: reverting only utils.ts to its parent commit makes both new cases time out, while the full PR state passes packages/node/src/utils.test.ts, the node package plus tests/signal-and-cancel.test.ts, and tsc -b. I also confirmed empirically that the drain's concurrent iterator.next() next to an in-flight pull is safe on Node 24 (chunks delivered once, no throw), and that no README/CHANGELOG documents the old cancel semantics.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (default — pick a model for stronger reviews) ｜ 𝕏}