[dinwwwh]

Summary

This PR fixes improper stream body handling when responding to HTTP/2 HEAD requests. Previously, stream bodies were not being properly released when sent in response to HEAD requests, causing resource leaks. The fix ensures that stream bodies are destroyed when the response connection closes, particularly for HTTP/2 where the underlying stream may end before the response object.

Key Changes

• Stream cleanup on connection close: Modified both @standard-server/node and @standard-server/fastify response handlers to listen for close events on the underlying connection stream (for HTTP/2) rather than just the response object, ensuring proper cleanup when the stream ends.

• HTTP/2 stream detection: Updated code to detect HTTP/2 responses by checking for the stream property and using that for event listeners instead of the response object directly, since HTTP/2 streams may end before the response object reports it.

• Improved abort signal handling: Refactored toAbortSignal in signal.ts to properly handle HTTP/2 HEAD requests where the stream is already ended when the handler runs. The signal now correctly detects when the stream is destroyed and aborts appropriately.

• Simplified response writability check: Streamlined canWriteToNodeResponse to focus on the essential checks (headersSent, writableEnded, and destroyed) rather than checking multiple stream state properties, making it more reliable for both HTTP/1 and HTTP/2.

• Comprehensive test coverage: Added extensive tests for:

  • HTTP/2 HEAD requests with stream bodies (both auto-exposed and explicit routes)
  • Stream cleanup on client-initiated stream resets with various error codes
  • Abort signal behavior on HTTP/2 HEAD responses
  • Response writability checks for HTTP/2 HEAD requests

Implementation Details

• The fix uses the 'stream' in res pattern to detect HTTP/2 responses and access the underlying stream for event listeners
• Stream bodies are explicitly destroyed in close handlers to ensure cleanup even when Fastify's automatic cleanup doesn't occur
• Tests verify both successful cleanup and proper error propagation when streams are reset by clients

https://claude.ai/code/session_019TvbqaqZZZK5rU6p35jamj

[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@117

@standard-server/core

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

@standard-server/fastify

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

@standard-server/fetch

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

@standard-server/node

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

@standard-server/peer

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

@standard-server/shared

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

commit: 1b4167d

[codspeed]

Merging this PR will not alter performance

✅ 26 untouched benchmarks
⏩ 108 skipped benchmarks¹

---

_{Comparing claude/gifted-darwin-vczbsc (1b4167d) with main (c6342d0)}

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. ↩

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[pullfrog]

ℹ️ No blocking issues. One optional consistency nit inline, plus a stale test comment noted below.

Reviewed changes

• HTTP/2 HEAD writability — canWriteToNodeResponse now treats an already-ended underlying stream (the HTTP/2 HEAD case) as writable, keying off res.writableEnded rather than the underlying stream's write state, and drops the old _canWriteToStream helper.
• Connection-scoped lifecycle — the Node and Fastify response adapters attach error/close to the underlying Http2Stream when present ('stream' in res), and release a stream body once that connection closes, so an endlessly-piping body no longer leaks on HEAD.
• Abort signal rework — toAbortSignal resolves the connection stream once, invokes onClose immediately when it is already destroyed, and decides the abort on !res.writableEnded, routing the response error through the shared handler.
• Test coverage — new HTTP/2 HEAD / client-reset / abort tests in the Node and Fastify packages, plus HEAD cases in the e2e data-transfer and signal-and-cancel suites. I ran the four package test files (61 tests) and both e2e suites (558 tests) plus pnpm run type:check — all green.

ℹ️ Nitpicks

• packages/node/src/utils.test.ts:620 — the comment "what sendStandardResponse settles on" still describes res.once('close'), but this PR moved that settle point to res.stream close. Switching the listener (and comment) to res.stream would keep the test mirroring production.
• packages/fastify/src/response.ts:40 — see inline note on error parity with the Node adapter.

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