ByteVeda / ByteVeda/flexiq

testing: the wall-time scheduler case flakes under a full run

Open
#924 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P2 rust tests
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 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.