Repository navigation
test(js/net): quarantine two tests that flake under load - #8333
Conversation
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 19 minutes. 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. |
There was a problem hiding this comment.
ℹ️ No critical issues — one tracking gap inline.
Reviewed changes
- Quarantined compressed-frame cap test —
js/net/src/group.test.tsturns the 32 MiB worst-case-slice test intotest.skip, citing bun's 5 s per-test timeout under load. - Quarantined re-offer test —
js/net/src/lite/publisher.test.tsskips the draft-07 redropped-reoffer test, citing its dependence on a singleflush()ordering update 3 ahead of the re-offer opening.
Quarantining rather than loosening a timeout or budget matches the flaky-test rule, and the PR body's investigation is specific enough to act on.
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed ba0889d.
No actionable findings. The diff only quarantines the two identified load-sensitive tests with test.skip and follow-up references; assertions and production behavior are unchanged. This removes their CI coverage rather than fixing the suspected timeout/order issues. Verification: static diff review only; the reported load reproductions were not independently rerun.

Problem
Two
js/nettests fail intermittently under CPU load. moq-dev/moq#8326 saw them in two of five whole-package runs under 48 CPU burners, without naming them. Rerunning the wholejs/netpackage 30 times under 48 burners on 24 cores (on7d91a5b634) failed 3 runs, all on these two:js/net/src/group.test.ts: "a compressed frame is refused unless its worst-case slice fits a peer's frame cap", 2/30 runs.js/net/src/lite/publisher.test.ts: "lite draft-07: a re-offer dropped again before it opens stays stale at the end", 1/30 runs.Approach
Quarantine both with
test.skipand a comment pointing at a follow-up quest, per the flaky-test rule. No code or assertion changes.Impact
None; tests only. No public API, no wire change.
Follow-ups
Plan one quest per test under
quest/m0/test-flakes-2/:compressed-frame-cap.md: the test hit bun's 5000 ms per-test timeout (5840 ms and 10442 ms under load; about 0.85 s alone with the host near load 50). It deflates and inflates a random payload of nearly 32 MiB, so it looks CPU-bound rather than racy, like the flate tail-shed test fixed in moq-dev/moq#8137. Suspected fix: prove the worst-case-slice cap without a full-size payload, for example by deriving the bound from a small input or checkingencodabledirectly. Recommendation: plan it.redropped-reoffer.md: failed in 22 ms withholesToEndreturning[]where[["drop", 1n, 1n, 3n]]was expected (publisher.test.ts:1572), so no stale drop stood at the end.Budget.pollis already stubbed, so the write budget is not the cause. The test sends update 2, yields once (flush()is oneyieldNow()), then sends update 3, relying on update 3 arriving inside the task the publisher yields after update 2, before the re-offer of group 1 opens. Suspected cause, not confirmed: under load that one yield is not enough ordering, so the re-offer opens (and is served) before update 3 re-drops it. A fix should wait on an event, such as the re-offer being queued, rather than a host-task count. Recommendation: plan it.A targeted
--rerun-each 300of the re-offer test under load did not run: it waited inquest gatebehind a host-wide hold until its time limit.Review
Skipped at ba0889d: the change only turns two
test(...)calls intotest.skip(...)with a comment each.Models
Size: S
Implementer: Claude Code, Opus 5.5, high effort
🤖 Generated with Claude Code
(Written by Opus 5.5 with high)