Repository navigation
test(cmux-next): the busy work-queue test bounds against its deadline, not 100 ms - #17655
Conversation
…, not 100 ms The property is that a full queue answers busy instead of waiting, and a waiting queue would only answer at the deadline. A 100 ms bound measured 289 ms on a loaded runner (#17611); the bound is now 10 s against a 30 s deadline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
Not verified: macOS jobs did not run: compile and app tests were skipped on CI passes on Written by |
…rk-queue-busy-timing
|
Batch queue: dropped from this batch, turns heavy tier red.
Next: fix, push. |
|
Found 23 test failures on Blacksmith runners: Failures
...and 13 more test failures. View all on Blacksmith
|
Summary
MainActorWorkQueueTests.failsFastWithBusyBeyondTheLimitmeasured 0.289 s against a 100 ms bound on #17611 under the full parallel suite.The test needs to show that a full queue answers
busyright away instead of waiting for room. No frame fires before the third call, so a queue that waited could only answer when the deadline expired, and it would answer with a timeout, notbusy. The deadline is now 30 s and the bound is 10 s, so the test still catches a waiting queue and a loaded runner can't trip it.Test-only.
Testing
cmux-next swift testjob is the green check.Changelog
none
🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by cubic
Fixes a flaky
MainActorWorkQueueTestsfailure that measured 289 ms against a 100 ms bound under the full parallel suite.Written for commit 87e992d. Summary will update on new commits.
Note
Low Risk
Test-only timing and documentation changes with no production code impact.
Overview
Relaxes timing in
failsFastWithBusyBeyondTheLimitso it stays reliable on loaded CI: the request deadline goes from 5 s to 30 s, and the assertion that the third call returnsbusyquickly is loosened from 100 ms to 10 s (still well under the deadline so a queue that waits for a timeout would still fail).Adds an inline comment documenting that the old 100 ms ceiling flaked at ~289 ms on a parallel runner (#17611). Test-only; production
MainActorWorkQueuebehavior is unchanged.Reviewed by Cursor Bugbot for commit 87e992d. Bugbot is set up for automated code reviews on this repo. Configure here.