Skip to content

test(net): a JS SETUP refusal has one rejection owner - #7083

Merged
kixelated merged 5 commits into
mainfrom
quest/m1/js-setup-rejection
Oct 29, 2026
Merged

kixelated merged 5 commits into
mainfrom
quest/m1/js-setup-rejection

Conversation

@kixelated

@kixelated kixelated commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

Finishes quest/m1/js-setup-rejection.md (deleted here, with its link in quest/m1/README.md).

Root cause

Every Writer.write in js/net/src/stream.ts polls a module-global Budget (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 a MessageChannel. 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 SETUP creates accepting = accept(...), then awaits the client's SETUP write before attaching expect(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.now so 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 reported no common version found; client offered: ff00000e from accept.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 version from connect.ts).

Ownership

The handler belongs to the test. accept() and connect() 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 .catch on the server test, so after merging main this PR keeps that version. It adds the client side and tightens the version matrix:

  • a client refuses ... selected in the moql SETUP observes connecting when it is created (same comment and idiom as main's server fix), matching the existing precedent in js/net/src/ietf/subscriber.test.ts. The refusal assertions, the error, and the close behavior are unchanged.
  • Both refusal tests now run over every supported moq-transport draft (Object.values(Ietf.Version), today 18 and 22) instead of the long-dropped draft 14. A regression that let the moql SETUP negotiate a supported IETF draft would still have refused 14, so the old test could not catch it. The matrix now follows js/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).rejects before driving the peer, deadlocks: Bun's rejects matcher runs the event loop synchronously until the promise settles, so the test never reaches the peer's write.

I audited every await expect(x).rejects in js/ whose promise is held across an await, plus every held accept/connect promise in js/net. Elsewhere the rejection is either triggered by the test after the awaits, or the promise is already observed.

Verification

  • With the stub at every offset from 0 to 40, both tests failed exactly once without the fix (server at 28, client at 20) and never with it. That was measured before fix(js): yield host tasks through the injected clock #6988 moved the yield onto the injected clock; the race it guards is unchanged.
  • just ci origin/main passes 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

  • No regression test added. A faithful test needs a stubbed clock plus a write-count offset tied to the budget's private batch size of 32. That would be brittle and would only cover this old bug.
  • Fixed the sibling client-side test in the same PR, since it is the same problem.
  • Parameterized over Ietf.Version rather than hard-coding draft 22, so the refusal follows whatever drafts JS supports (maintainer scope note, 2026-10-29).

Impact

  • Public API: none.
  • Wire: none.

Suggested follow-ups

  • Make the write budget's yield reachable deterministically in tests (for example, a test hook or a counter owned by the mock transport). Today, any test that holds a promise across a stream write can fail depending on load and test order, and no test exercises the yield path on purpose.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

kixelated and others added 2 commits October 28, 2026 03:41
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>
@kixelated kixelated changed the title A JS SETUP refusal has one rejection owner test(net): a JS SETUP refusal has one rejection owner Oct 28, 2026
@kixelated
kixelated marked this pull request as ready for review October 28, 2026 10:55
@coderabbitai

coderabbitai Bot commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You'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.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 97265038-0f9d-48fb-8aa0-4587b15b2189
Commits

Reviewing files that changed from the base of the PR and between b9a11ae and 28fca0f.

Files selected for processing: 3
  • js/net/src/connection/connect.test.ts
  • quest/m1/README.md
  • quest/m1/js-setup-rejection.md
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 28, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-29T07:27:47.691338Z 28fca0f New commits
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@kixelated kixelated left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

kixelated and others added 3 commits October 28, 2026 22:45
# 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 kixelated left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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)

@kixelated

Copy link
Copy Markdown
Collaborator Author

Landing summary: this head (28fca0f) adds the client-side .catch to the moql SETUP refusal test, keeps main's server-side fix from moq-dev/moq#6988, and runs both refusal tests over every supported IETF draft. It also deletes the finished quest quest/m1/js-setup-rejection.md.

  • Reviews on this head: Codex (thumbs up, no findings) and the automated review from the maintainer account (no actionable bugs). No unresolved threads.
  • Checks: 12 passed. quest check --base origin/main passes.
  • This session took over a stale quest:merge hold, as the maintainer authorized. The earlier merge pick still applies.

(Written by Claude Opus 5.5)

@kixelated
kixelated added this pull request to the merge queue Oct 29, 2026
Merged via the queue into main with commit 3637559 Oct 29, 2026
12 checks passed
@kixelated
kixelated deleted the quest/m1/js-setup-rejection branch October 29, 2026 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant