scheduler::tests::test_outcomes_carry_measured_wall_time fails intermittently under a full cargo test --workspace, and passes in isolation and on a clean re-run.
---- scheduler::tests::test_outcomes_carry_measured_wall_time stdout ----
thread 'scheduler::tests::test_outcomes_carry_measured_wall_time' panicked at crates/flexiq-core/src/scheduler/mod.rs:1229:34:
called `Result::unwrap()` on an `Err` value: JobNotFound("01a08e22-66df-7132-ad29-ef0e61e41642")
Seen once in 479 tests during the #916 gate, then green on a re-run of the same suite and green with --exact on its own. The branch it surfaced on had an empty diff against crates/flexiq-core/.
Where to look
scheduler/mod.rs:1229 unwraps a get_job inside test scaffolding rather than in the scheduler itself. Under load the job appears to be gone by the time the assertion reads it back — the likely candidates being a concurrent sweep or archival having moved it, or a claim/complete ordering the test assumes but does not enforce.
Two things worth fixing regardless of the root cause:
- The
unwrap is the reason this reads as a panic rather than an assertion. A test reading a job it expects to exist should say so, so a failure names the expectation instead of the Result.
- A test whose subject is wall-clock measurement is a likely candidate for timing assumptions that hold on an idle machine and not on a loaded one.
Low priority — it does not gate anything today and re-runs pass — but it is the kind of flake that eventually costs someone an afternoon on an unrelated PR, which is how it surfaced here.
scheduler::tests::test_outcomes_carry_measured_wall_timefails intermittently under a fullcargo test --workspace, and passes in isolation and on a clean re-run.Seen once in 479 tests during the #916 gate, then green on a re-run of the same suite and green with
--exacton its own. The branch it surfaced on had an empty diff againstcrates/flexiq-core/.Where to look
scheduler/mod.rs:1229unwraps aget_jobinside test scaffolding rather than in the scheduler itself. Under load the job appears to be gone by the time the assertion reads it back — the likely candidates being a concurrent sweep or archival having moved it, or a claim/complete ordering the test assumes but does not enforce.Two things worth fixing regardless of the root cause:
unwrapis the reason this reads as a panic rather than an assertion. A test reading a job it expects to exist should say so, so a failure names the expectation instead of theResult.Low priority — it does not gate anything today and re-runs pass — but it is the kind of flake that eventually costs someone an afternoon on an unrelated PR, which is how it surfaced here.