Skip to content

quic: destroy stream on invalid promise body - #66260

Open
christianaurichzm wants to merge 1 commit into
nodejs:mainfrom
christianaurichzm:quic-promise-body-invalid
Open

christianaurichzm wants to merge 1 commit into
nodejs:mainfrom
christianaurichzm:quic-promise-body-invalid

Conversation

@christianaurichzm

Copy link
Copy Markdown
Contributor

stream.setBody(Promise.resolve(42)) crashes the process with an unhandled rejection, while stream.setBody(42) throws ERR_INVALID_ARG_TYPE synchronously.

const stream = await clientSession.createBidirectionalStream();
stream.setBody(Promise.resolve(42));

configureOutbound() calls itself with the resolved value inside the fulfillment handler of PromisePrototypeThen(). The rejection handler only covers body itself rejecting, so when that call throws, the error goes to the promise returned by PromisePrototypeThen(), which nothing handles.

This moves the rejection handler to a second PromisePrototypeThen(), so it catches both cases and destroys the stream with the error. The same goes for ERR_INVALID_STATE when the promise resolves to a FileHandle already in use by another stream. A rejected body now destroys the stream one microtask later.

On main the new test crashes. With this change all test/parallel/test-quic-*.mjs tests pass and make lint is clean.

When `setBody()` receives a promise that resolves to an unsupported
body type, `configureOutbound()` throws inside the fulfillment
handler. The rejection handler only covered the original promise, so
the error rejected a discarded promise and crashed the process as an
unhandled rejection.

Chain the rejection handler after the fulfillment handler so both
cases destroy the stream with the error. For an unsupported resolved
value, `stream.closed` now rejects with the same
`ERR_INVALID_ARG_TYPE` that `setBody()` throws synchronously.

Signed-off-by: Christian Aurich Zanettini Martins <christian.aurichzm@gmail.com>
@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/quic

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

codecov Bot commented Sep 24, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.28%. Comparing base (24b9ca9) to head (3649ec9).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #66260      +/-   ##
==========================================
- Coverage   90.30%   90.28%   -0.03%     
==========================================
  Files         789      789              
  Lines      272880   272883       +3     
  Branches    52106    52107       +1     
==========================================
- Hits       246423   246369      -54     
- Misses      16918    16976      +58     
+ Partials     9539     9538       -1     
Files with missing lines Coverage Δ
lib/internal/quic/quic.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.

@pimterry pimterry left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @christianaurichzm! Good find, fix LGTM.

Would be nice to avoid the extra Then step imo, but I don't feel strongly.

Comment thread lib/internal/quic/quic.js
body,
(resolved) => configureOutbound(handle, stream, resolved),
),
undefined,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: this adds another promise layer, which adds a microtask step and a small perf cost on every request, and we're only trying to catch sync errors so that layer's not really necessary.

Could we rewrite to use a try/catch inside the fulfilment step instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-ci PRs that need a full CI run. quic Issues and PRs related to the QUIC transport implementation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants