testing: the wall-time scheduler case flakes under a full run
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 20
- Forks
- 2
- Avg merge
- 5h 10m
- Merged PRs (30d)
- 127
Description
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
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. - 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in crates/flexiq-core/src/scheduler/mod.rs at scheduler::tests::test_outcomes_carry_measured_wall_time and the get_job unwrap around line 1229. Run cargo test --workspace, then the test with --exact to reproduce the difference and inspect the scheduler's sweep, archival, and claim/complete ordering. Done means the wall-time test remains reliable under the full suite and reports an assertion instead of an opaque unwrap panic.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100