Make cancelled-JoinError test fixture deterministic - #140
Conversation
The logs_failures::case_3 fixture spawned a task that yields once and completes, then aborted it on a multi-threaded runtime. The spawned task ran concurrently on a worker thread, so under load it could finish before abort() took effect, making handle.await return Ok(()) and the unwrap_err() call panic. This intermittently failed the cargo-mutants unmutated baseline while plain CI stayed green. Abort a task awaiting std::future::pending::<()>() instead, on a current-thread runtime: the task can never complete and is not even polled before the abort, so the JoinError is always the cancelled variant. Reproduced at roughly 1 failure per 100 runs before the change; 500 consecutive runs pass after it. Closes #139.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 33 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Closes #139.
Summary
The cargo-mutants unmutated baseline intermittently failed on
supervisor::tests::logs_failures::case_3(run 29074661946) while plain CIstayed green. The defect is not the log-capture path — the test already uses a
scoped
with_defaultsubscriber — but a race in the test fixture that buildsthe cancelled
JoinError.create_cancelled_join_errorspawned a task that yields once and thencompletes, on a multi-threaded runtime, and aborted it afterwards. The spawned
task runs concurrently on a worker thread, so under load it can finish before
abort()lands;handle.awaitthen returnsOk(())andunwrap_err()panics (
called Result::unwrap_err() on an Ok value). Machine load explainsthe execution-shape dependence: cargo-mutants' baseline runs on a busier
machine profile than the plain
make testjob.Fix
Abort a task awaiting
std::future::pending::<()>()on a current-threadruntime. The future can never complete, and on a current-thread runtime the
task cannot even be polled before
block_onregains control, so the abortalways produces the cancelled
JoinError. Test semantics are unchanged: thefixture still hands
log_task_failurea genuine cancelledJoinError.Review walkthrough
crates/comenqd/src/supervisor/tests.rs—
create_cancelled_join_errornow uses a current-thread runtime and anever-completing future; the doc comment records why.
Validation
comenqdtestbinary's
logs_failuresfilter repeatedly failed with the exact panic attests.rs:36(unwrap_err()onOk) roughly once per 100 runs.cargo test --workspace --all-features(the cargo-mutants baseline shape,with the caller's extra-args) passed three consecutive full runs.
make check-fmtandmake lint(Clippy; the Whitaker Dylint suite runs inCI) pass.