Repository navigation
test(net): a JS SETUP refusal has one rejection owner - #7083
Conversation
Quest-Claim: 62e2e3cba2a1efaa
The shared stream write budget can yield a host task right after a SETUP write. Both moql SETUP refusal tests held the handshake promise unobserved across that write, so the refusal could land first and Bun reported it as an unhandled rejection. Observe each promise when it is created; the refusal assertions are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 1 minute. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: f336e62
No actionable bugs found. Observing both handshake promises immediately in the refusal tests is a small, appropriate fix at the caller boundary: the original promises still reach the unchanged rejection assertions, while production rejection behavior remains intact. The write budget can cross a host-task boundary before those assertions attach, consistent with the reported failure mechanism.
Verification: static inspection of the changed tests, handshake error handling, and shared write-budget scheduling. I did not run tests or reproduce the reported timing-offset experiment; its results are not independently verified.
# Conflicts: # js/net/src/connection/connect.test.ts
The refusal tests used draft 14, which no longer exists anywhere, so a regression that let the `moql` SETUP negotiate a supported moq-transport draft would still pass. Run both sides over every `Ietf.Version`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 28fca0f
No actionable bugs found in the substantive update since f336e62. Testing every currently supported IETF version is a meaningful improvement over only rejecting obsolete draft 14: it can catch accidental cross-protocol negotiation that the old case would miss. The version object contains numeric draft 18/22 values, and both directions preserve their exact refusal assertions and immediate promise observation. The server-side handler now present in the base is not a new fix in this revision.
Direction: keep this at the test boundary; no production rejection swallowing or broader handshake redesign is needed. Deterministically exercising the budget-yield race remains the already documented follow-up.
Verification: base-aware comparison of the earlier/current test cases, current version definitions and SETUP refusal paths. No tests or timing experiments run, and reported CI results were not independently reproduced.
(written by OpenAI)
|
Landing summary: this head (28fca0f) adds the client-side
(Written by Claude Opus 5.5) |
Finishes quest/m1/js-setup-rejection.md (deleted here, with its link in
quest/m1/README.md).Root cause
Every
Writer.writeinjs/net/src/stream.tspolls a module-globalBudget(js/net/src/util/yield.ts). On every 32nd poll, once 4 ms of real time has passed since the last yield, the write yields a host task through aMessageChannel. The count is shared by the whole process and the slice is wall-clock time, so whether a given write yields depends on how many writes earlier tests made and on machine load. That explains why the failure showed up only in full-file or full-package runs under load and never in a focused run.a server refuses a client offering only IETF versions in the moql SETUPcreatesaccepting = accept(...), then awaits the client's SETUP write before attachingexpect(accepting).rejects. If that write yields, the server decodes the SETUP and rejects during the same microtask drain, before the test attaches a handler. Bun then reports the rejection as unhandled at the task boundary.Reproduced deterministically by stubbing
performance.nowso every budget check finds its slice spent, then prefixing N one-byte writes: N = 28 makes the SETUP write the 32nd poll, and the original test fails with the reportedno common version found; client offered: ff00000efromaccept.ts:187. The sibling client test,a client refuses an IETF version selected in the moql SETUP, has the same shape and fails the same way at N = 20 (unsupported server versionfromconnect.ts).Ownership
The handler belongs to the test.
accept()andconnect()return their promise to the caller, and all internal promises (pending,terminal, the abort race) are already observed. A caller that holds the promise unobserved across a task boundary owns that unhandled rejection. Swallowing it inside production would hide real unhandled rejections from callers.Change
moq-dev/moq#6988 has since landed the same
.catchon the server test, so after mergingmainthis PR keeps that version. It adds the client side and tightens the version matrix:a client refuses ... selected in the moql SETUPobservesconnectingwhen it is created (same comment and idiom as main's server fix), matching the existing precedent injs/net/src/ietf/subscriber.test.ts. The refusal assertions, the error, and the close behavior are unchanged.Object.values(Ietf.Version), today 18 and 22) instead of the long-dropped draft 14. A regression that let themoqlSETUP negotiate a supported IETF draft would still have refused 14, so the old test could not catch it. The matrix now followsjs/net/src/ietf/version.ts, so it stays aligned with the moq-transport trimming in moq-dev/moq#7194. JS carries no draft 20.The obvious alternative, attaching
expect(p).rejectsbefore driving the peer, deadlocks: Bun'srejectsmatcher runs the event loop synchronously until the promise settles, so the test never reaches the peer's write.I audited every
await expect(x).rejectsinjs/whose promise is held across anawait, plus every heldaccept/connectpromise injs/net. Elsewhere the rejection is either triggered by the test after the awaits, or the promise is already observed.Verification
just ci origin/mainpasses on the merged head (JS check and test, quest, markdown, gh, and the repo-wide lints), and the four parameterized refusal cases pass.Choices made without asking
Ietf.Versionrather than hard-coding draft 22, so the refusal follows whatever drafts JS supports (maintainer scope note, 2026-10-29).Impact
Suggested follow-ups
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code