ci: quarantine worker transfer-terminate tests on ASAN; widen node-net mimalloc threshold

[robobun]

What

Stops three test files from turning unrelated PR builds red on main. All three are pre-existing failures that the CI annotation tagger marks [pre-existing] on every PR that hits them.

Surveyed builds 75470–75621 via the Buildkite /annotations API:

test	lane	signature
test-worker-message-port-transfer-terminate.js	debian 13 x64-asan only	SIGABRT, JSObject.cpp:3936 (11/12) / JSCJSValuePropertyInlines.h:51 (1/12)
worker-transfer-terminate-stress.test.ts	debian 13 x64-asan only	SIGABRT, ExceptionScope.h:61 assertNoException (6/6)
node-net.test.ts (one case)	alpine 3.23 aarch64, debian 13 aarch64, ubuntu 25.04 aarch64/x64-baseline, darwin 26 aarch64	mimalloc page delta 10..14

Worker transfer-terminate (ASAN quarantine)

Two distinct crash paths, both x64-asan only, release lanes unaffected:

Vendored test (test-worker-message-port-transfer-terminate.js): worker.terminate() lands while a process.* lazy PropertyCallback builder (stdout/stderr/stdin/nextTick/mainModule, via setupWorkerStdio) is in JS; tryClearException() refuses to clear the TerminationException, so the builder returns with it pending and reifyStaticProperty reports the slot found, tripping:

ASSERTION FAILED: !scope.exception() || !result
vendor/WebKit/Source/JavaScriptCore/runtime/JSObject.cpp(3936) : bool JSC::JSObject::getOwnPropertyDescriptor(...)

Tracked in #34095; fix PRs #33966 and #33418. Remove this entry once either lands. Verbatim upstream port we do not edit.

Stress test (worker-transfer-terminate-stress.test.ts): the bun-owned 8×10-worker amplification of the above, but on CI it only ever hits:

ASSERTION FAILED: (null)
!exception()
vendor/WebKit/Source/JavaScriptCore/runtime/ExceptionScope.h(61) : void JSC::ExceptionScope::assertNoException()

6/6 observed (builds 75493/75495/75514/75597/75604/75606). #33966's Verification section reports this path still reproducing at ~1/4000 workers after its lazy-builder fix ("termination landing later in the bootstrap, after the stdio builders have completed"), so it is not the same bug. Tracked separately in #34690; this entry is not removable with the vendored-test entry.

node-net.test.ts threshold

Only one case fails: should not leak when connect({path}) fails synchronously on a reused handle. It asserts the mimalloc page delta across two equal 8000-iteration runs is < 10.

error: mimalloc page count: 128 -> 139
Expected: < 10
Received: 11

Since #34009 JSC shares mimalloc, and on aarch64/darwin release lanes its heap adds up to +14 of noise over the measured run even after the equal-size warmup (observed deltas across style=error + style=warning annotations: 10, 10, 10, 10, 10, 10, 10, 11, 11, 11, 11, 11, 12, 12, 12, 13, 13, 14). The native-socket leak this test guards against shows +25 per 8000 iterations on release, so raising the threshold to 20 keeps clear separation from both the observed noise ceiling and the leak signal. The file stays in the run everywhere; per the expectations.txt header, a single broken case is fixed in-file, not quarantined.

Not in this PR

test/js/node/test/parallel/test-net-connect-memleak.js (the fourth file in the original report) fails only on linux-x64-musl with the onGC/FinalizationRegistry timing issue and is handled by #34631 (which also covers its test-gc-http-client* siblings) and #33045.

Verification

Parsing test/expectations.txt with the runner's own filtering (replicated from scripts/runner.node.mjs getRelevantTests):

ASAN (debian 13 x64-asan):
  SKIP js/node/test/parallel/test-worker-message-port-transfer-terminate.js
  SKIP js/node/worker_threads/worker-transfer-terminate-stress.test.ts
  RUN  js/node/net/node-net.test.ts

LINUX-X64 (glibc), LINUX-X64-MUSL, DARWIN-AARCH64, WINDOWS-X64:
  RUN  (all three)

Build 75622 on this branch: neither worker test appeared in the x64-asan lane's annotations and node-net.test.ts did not appear on any lane, so the filtering and threshold are working. The remaining red on that build was pre-existing (node-http-server-socket-end-drain.test.ts on darwin 14 x64, test-net-connect-memleak.js on alpine x64; both owned by other sessions) plus a darwin 26 tart-VM provisioning failure.

No source changes; this is test-infra only, so there is no fail-before/pass-after to capture.

---

no test proof · iteration 0 · Platform-specific test-only change; deferring to CI.

[robobun]

Test-infra only; no source changes, so no fail-before/pass-after proof applies.

Diff is green. Across both CI runs (builds 75622 and 75654), none of the three files this PR touches appear in any failure annotation: both worker tests are correctly skipped on x64-asan and node-net.test.ts passes on every lane including alpine/debian/ubuntu aarch64 and darwin.

Remaining red on both builds is the same two [pre-existing] failures, neither touched by this diff and both owned by other work:

• test/js/node/test/parallel/test-net-connect-memleak.js on alpine x64 / x64-baseline: the linux-x64-musl onGC timing issue handled by test: quarantine onGC-based Node compat tests on linux-x64-musl #34631 / Quarantine test-net-connect-memleak on linux-x64-musl #33045.
• test/js/node/http/node-http-server-socket-end-drain.test.ts on darwin 14 x64 / darwin 26 aarch64: pre-existing on main, being handled separately.

Everything else was retry-passed flake. Ready for a maintainer to merge.

Self-review corrections (in 2936941): the stress test's CI crashes are all ExceptionScope.h:61, a path #33966 says survives its fix, so it now has its own tracker (#34690) and separate removal criteria; and the error-only survey missed a darwin retry-passed hit at delta=14, so the threshold is 20 (not 18) and the comment is corrected.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 5 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 88fd63b8-73a6-4d44-831d-461139552f6f

📥 Commits

Reviewing files that changed from the base of the PR and between f5ba155 and 2936941.

📒 Files selected for processing (2)

• test/expectations.txt
• test/js/node/net/node-net.test.ts

---

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

[robobun]

^{Updated 11:46 PM PT - Jul 18th, 2026}

❌ @robobun, your commit 2936941 has 2 failures in Build #75654 (All Failures):

• test/js/node/http/node-http-server-socket-end-drain.test.ts - code 1 on 🍎 26 aarch64
• test/js/node/http/node-http-server-socket-end-drain.test.ts - code 1 on 🍎 14 x64
• test/js/node/test/parallel/test-net-connect-memleak.js - code 1 on 🐧 3.23 x64
• test/js/node/test/parallel/test-net-connect-memleak.js - code 1 on 🐧 3.23 x64-baseline

---

🧪   To try this PR locally:

bunx bun-pr 34686

That installs a local version of the PR into your bun-34686 executable, so you can run:

bun-34686 --bun

[claude]

LGTM — test-infra only, no runtime code touched.

What was reviewed:

• Both new [ ASAN ] entries in expectations.txt name real files, match the existing format/modifier, and carry the required comment naming the tracked issue (#34095) and fix PRs.
• Substring matching won't over-quarantine: neither path is a prefix of any other test file.
• The mimalloc threshold widening (10 → 18) still sits well below the +25-page leak signal the test guards against, so the assertion can still fail for the right reason.

Extended reasoning...

Overview

Two files changed, both in test/:

• test/expectations.txt: adds two [ ASAN ] quarantine entries for test-worker-message-port-transfer-terminate.js and worker-transfer-terminate-stress.test.ts, with a detailed comment block explaining the JSC !scope.exception() || !result assertion, the tracking issue (#34095), and the open fix PRs (#33966, #33418).
• test/js/node/net/node-net.test.ts: raises one leak-test threshold from toBeLessThan(10) to toBeLessThan(18) and updates the accompanying comment to explain the JSC-shares-mimalloc noise since #34009.

No source code is modified; this is purely CI quarantine + a de-flake threshold adjustment.

Security risks

None. No runtime code, no auth/crypto/permissions, no user-facing behavior change.

Level of scrutiny

Low. This is a mechanical test-infra change that follows the file's own header rules exactly: whole-file crashes go in expectations.txt with a modifier and comment; a single flaky case is fixed in-file rather than quarantining the whole file. Both patterns are applied correctly here.

I verified:

• Both quarantined test files exist at the stated paths.
• The [ ASAN ] modifier and [ CRASH ] expectation match the surrounding entries' format exactly, so the runner's substring parser will pick them up on the ASAN lane only (release lanes keep running both).
• The entries are full unique paths, so substring matching won't accidentally quarantine sibling tests.
• The threshold change preserves the test's purpose per REVIEW.md's de-flaking rule ("keep asserting the property the original assertion protected"): the guarded leak produces +25 pages on release, the observed noise ceiling is +13, and 18 sits between them with clear separation on both sides.

Other factors

The PR body is thorough — it cites the Buildkite survey (builds 75470–75621), per-lane hit counts, the exact assertion text, and a per-lane filtering verification against scripts/runner.node.mjs. Every skip/weakening carries a stated reason and a removal condition, satisfying the repo's "never silently weaken" rule. No prior human reviews or outstanding comments to address.

[claude]

LGTM — test-infra only, no source changes.

What was reviewed:

• Both [ ASAN ] quarantine entries follow the file's format, cite tracking issues (#34095/#34690) and removal conditions, and are scoped so release lanes keep running the tests.
• The mimalloc threshold widening (10→20) still sits below the +25 leak signal the test guards against, so the assertion can still fail for the right reason.
• Checked substring-match semantics in expectations.txt — the two new paths don't prefix-match any unrelated test files.

Extended reasoning...

Overview

Two-file test-infra change: (1) test/expectations.txt gains two [ ASAN ] quarantine entries for test-worker-message-port-transfer-terminate.js and worker-transfer-terminate-stress.test.ts, both of which SIGABRT on the debian-13 x64-asan lane with a known JSC TerminationException-during-lazy-PropertyCallback assertion; (2) test/js/node/net/node-net.test.ts widens one leak-regression threshold from < 10 to < 20 mimalloc pages and updates the explanatory comment.

Security risks

None. No runtime, native, or built-in JS code is touched — only a test expectations list and a numeric threshold in a test assertion.

Level of scrutiny

Low. This is a CI-flake quarantine PR following the exact patterns already established in both files. The expectations.txt header explicitly documents when file-level quarantine is appropriate (whole-file crash/hang) vs. in-file skip (single case), and the PR applies each correctly: the two crashing worker tests get [ ASAN ] file-level entries (they SIGABRT the whole process), while the single flaky node-net case is fixed in-file by adjusting the threshold rather than quarantining the entire 40+-test file.

Other factors

• Per REVIEW.md's "never silently weaken a test" rule: both quarantine entries carry detailed comments naming the observed assertion, build numbers, tracking issues, fix PRs, and explicit removal conditions. The stress-test entry even documents that it is not removable with the first entry (separate root cause per #33966's findings).
• The threshold change preserves the test's ability to catch the regression it guards: the comment and PR body state the actual leak produces +25 pages (release) / +163 (debug+ASAN), and observed JSC-shared-mimalloc noise tops out around +13–14. A threshold of 20 keeps clear separation on both sides.
• Minor: the PR description says "raising the threshold to 18" but the code (and the second commit message) landed on 20 to accommodate darwin noise — the code is internally consistent and the discrepancy is just stale PR-body text.
• Entries match by substring per the file header; both new paths are full and specific enough not to accidentally quarantine sibling tests.
• No prior reviews from me on this PR; no outstanding human reviewer comments.

[robobun]

test/js/node/test/parallel/test-http2-reset-flood.js hits the same ExceptionScope.h:61 assertNoException() on the same :debian: 13 x64-asan lane in 32 builds across 30 branches in the Jul 17-19 window (sample: 74637, 74674, 74703, 75493, 75713, 75718, 75735, 75757, 75773).

The test runs an http2.createServer in a Worker and calls worker.terminate() from the main thread once the connection errors (line 82). 4/4 sampled builds show:

ASSERTION FAILED: (null)
!exception()
vendor/WebKit/Source/JavaScriptCore/runtime/ExceptionScope.h(61) : void JSC::ExceptionScope::assertNoException()

Same signature as the stress-test entry you're adding here, so it likely belongs under the same #34690 tracker. Worth adding a third [ ASAN ] line for it alongside the other two.