quic: do not destroy incoming streams that have a consumer by trivenay · Pull Request #65335 · nodejs/node

trivenay · 2026-08-16T19:40:40Z

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay · 2026-08-16T19:40:40Z

Fixes: #64192

An incoming QUIC stream is currently destroyed at arrival unless the session has an onstream callback. That check is narrower than the ways a stream can actually be consumed: on an HTTP/3 session, the application layer drives incoming request streams through the session-level stream callbacks (onheaders, ontrailers, oninfo, onwanttrailers), and onstream is legitimately absent. Today such streams are destroyed out from under the h3 machinery, and the practical workaround is registering stub onstream handlers just to keep streams alive (as noted in the issue and in the WebTransport work in #63827).

This changes the arrival check to the broader invariant discussed in the issue: destroy an incoming stream only when the session has no consumer at all for it.

A consumer is either:

an onstream callback (any negotiated protocol), or
session-level stream callbacks, when the negotiated application actually produces header events. This is checked through the existing headersSupported session state, which the C++ side computes once when it selects the application from the negotiated ALPN — so the JS side reads a stored conclusion rather than re-deriving ALPN rules.

Notes on scope and safety:

Sessions with no consumers keep the current destroy-plus-warning behavior, so unconsumed streams cannot accumulate and hold flow control credit or MAX_STREAMS slots. (Kept streams that go idle are additionally bounded by streamIdleTimeout.)
The check is on the callback container, not on individual callback names — when a future consumer such as onsessionid (quic: Webtransport support quic/http 3 #63827) lands in the session-level stream callbacks, it participates with no further changes.
This path cannot affect HTTP/3's internal streams: control and QPACK streams are consumed inside nghttp3 and never exposed to JS (Http3Application::ReceiveStreamOpen), so only bidirectional request streams ever reach this check.
The check is not racy: callbacks are constructor-time configuration (listen()/connect() options), attached synchronously before the handshake that must complete before any peer stream can arrive, and the decision reads only session configuration — never stream content.

The new test covers both sides of the predicate: an HTTP/3 request completes on a session with only onheaders registered and no onstream (destroyed before this change), and stream callbacks registered on a session whose negotiated application cannot run them do not keep streams alive (destroyed with the warning, as before). The test was also validated against a build without this change, where the first case fails as expected. The existing test-quic-stream-uni-no-onstream continues to cover the no-callbacks-at-all case.

nodejs-github-bot · 2026-08-16T19:40:45Z

Review requested:

@nodejs/quic

codecov · 2026-08-16T21:25:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (f3a8f1a) to head (7ab7790).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65335 +/- ##
==========================================
+ Coverage 90.10% 90.12% +0.02% 
==========================================
Files 752 752 Lines 252207 252250 +43 Branches 47446 47444 -2 ==========================================
+ Hits 227254 227346 +92 + Misses 16261 16206 -55 - Partials 8692 8698 +6

Files with missing lines	Coverage Δ
lib/internal/quic/quic.js	`100.00% <100.00%> (ø)`
lib/internal/quic/state.js	`100.00% <100.00%> (ø)`

... and 32 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

nodejs-github-bot · 2026-08-17T20:45:11Z

CI: https://ci.nodejs.org/job/node-test-pull-request/75950/

trivikr

Can we update quic.md to reflect this behavior? It currently says all peer-initiated streams arrive through session.onstream. This PR makes onstream optional when the negotiated application supports configured stream callbacks - for example, HTTP/3 requests consumed through onheaders. The general stream description, session.onstream docs, and HTTP/3 server example should clarify this.

trivenay · 2026-08-18T22:46:39Z

@trivikr Updated quic.md in a fixup commit: the general stream description and session.onstream now note that stream-level callbacks count as a consumer for applications that support them (e.g. HTTP/3), and the minimal HTTP/3 server example calls out that onstream is optional there. Also converted the earlier follow-up commit to a fixup.

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: nodejs#64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com>

Signed-off-by: Naman Trivedi <trivenay@amazon.com>

nodejs-github-bot · 2026-08-20T03:19:20Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76029/

nodejs-github-bot · 2026-08-20T07:03:24Z

Landed in fd5b135

An incoming stream was destroyed unless the session had an onstream callback, even when session-level stream callbacks (onheaders et al) were registered and the negotiated application (HTTP/3) would drive the stream through them. Users had to register stub onstream handlers just to keep their streams alive. Destroy an incoming stream only when the session has no consumer for it at all: no onstream callback, and no session-level stream callbacks runnable on the negotiated application (checked via the existing headersSupported session state, computed when the application is selected from ALPN). Sessions with no consumers keep the current destroy-and-warn behavior so unconsumed streams cannot accumulate and hold flow control credit. On HTTP/3 sessions only bidirectional request streams reach this path; control and QPACK streams are consumed internally by nghttp3 and are never exposed to JavaScript. Fixes: #64192 Signed-off-by: Naman Trivedi <trivenay@amazon.com> PR-URL: #65335Fixes: #64192 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

trivenay mentioned this pull request Aug 16, 2026
quic: Should QuicStream be destroyed, if onstream is not set #64192
Closed

nodejs-github-bot added needs-ci PRs that need a full CI run. quic Issues and PRs related to the QUIC transport implementation. labels Aug 16, 2026

trivenay force-pushed the quic-stream-consumer-gate branch from 3b6d1fb to aa4680aCompare August 16, 2026 19:49

jasnell reviewed Aug 17, 2026
View reviewed changes

Comment threadlib/internal/quic/quic.js Outdated

jasnell approved these changes Aug 17, 2026
View reviewed changes

trivenay force-pushed the quic-stream-consumer-gate branch from aa4680a to ae555c6Compare August 17, 2026 12:45

trivikr reviewed Aug 17, 2026
View reviewed changes

trivenay force-pushed the quic-stream-consumer-gate branch from ae555c6 to 3b48565Compare August 18, 2026 22:46

trivikr requested changes Aug 19, 2026
View reviewed changes

Comment threadlib/internal/quic/quic.js Outdated

trivenay added 5 commits August 19, 2026 22:06

fixup! quic: do not destroy incoming streams that have a consumer
cb65ad6
Signed-off-by: Naman Trivedi <trivenay@amazon.com>

fixup! quic: do not destroy incoming streams that have a consumer
dbccdfa
Signed-off-by: Naman Trivedi <trivenay@amazon.com>

fixup! fixup! quic: do not destroy incoming streams that have a consumer
e432622
Signed-off-by: Naman Trivedi <trivenay@amazon.com>

fixup! quic: do not destroy incoming streams that have a consumer
7ab7790
Signed-off-by: Naman Trivedi <trivenay@amazon.com>

trivenay force-pushed the quic-stream-consumer-gate branch from 3b48565 to 7ab7790Compare August 19, 2026 22:07

trivikr added the request-ci Add this label to start a Jenkins CI on a PR. label Aug 19, 2026

trivikr mentioned this pull request Aug 19, 2026
quic: SIGSEGV on exit after a client writes to a unidirectional stream on an h3 session #65408
Closed

trivikr approved these changes Aug 19, 2026
View reviewed changes

trivikr added the author ready PRs with CI started, the required approvals, and no outstanding review comments. label Aug 19, 2026

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Aug 20, 2026

This comment was marked as outdated.
Sign in to view

trivikr added commit-queue-squash PRs the Commit Queue should land as one squashed commit. commit-queue PRs queued for automated landing through the Commit Queue. labels Aug 20, 2026

nodejs-github-bot merged commit fd5b135 into nodejs:mainAug 20, 2026
79 checks passed

nodejs-github-bot removed the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 20, 2026

github-actionsBot mentioned this pull request Aug 25, 2026
2026-08-26, Version 26.8.0 (Current) #65551
Merged