Skip to content

fix(tests): make two flaky test suites deterministic - #1771

Merged
potiuk merged 1 commit into
apache:mainfrom
potiuk:fix/flaky-cve-json-and-runner-tests
Oct 23, 2026
Merged

potiuk merged 1 commit into
apache:mainfrom
potiuk:fix/flaky-cve-json-and-runner-tests

Conversation

@potiuk

@potiuk potiuk commented Oct 23, 2026

Copy link
Copy Markdown
Member

Three tests failed intermittently under the full parallel run (the commit hook's workspace-pytest, and CI). They blocked commits that had nothing to do with them.

generate-cve-json: test_normalised_body.py saw DRAFT where it expected REVIEW

main(["--config", ...]) reloads the module-level config globals, and nothing restored them. TestReleaseVoteGating in test_cli.py passes a config with release_vote_gating = true. Any later test on the same xdist worker that called main() without --config ran under that config. Run in that order, the pair failed every time:

pytest -n0 "tests/test_cli.py::TestReleaseVoteGating::test_gating_on_without_label_stays_draft" \
  tests/test_normalised_body.py::test_a_complete_body_reaches_review

An autouse fixture in tests/conftest.py now puts the config back after any test that changed it. The CLI itself is unchanged: a real process exits after one run, so the leak only exists inside the test process.

adversarial-review: two runner tests raced the clock

  • test_one_timeout_does_not_block_the_others gave codex's stub a shared 5 s budget, already raised once from 1 s.
  • test_reviewers_run_in_parallel_and_keep_order required two 3 s sleeps to overlap.

On a loaded machine a fresh stub can start several seconds late. In one failure, one stub started almost 5 s after the other, after the other had already finished its 3 s sleep. So both failed now and then.

Both now use a handshake instead of a time window:

  • In the parallel test, each stub marks that it started and waits up to 20 s for the other's mark.
  • In the timeout test, gemini reports its timeout only after codex has answered. Gemini is listed first, so a sequential run would never start codex.

As a check, I made run_all sequential (max_workers=1) and confirmed both tests fail. They still test concurrency, not just the absence of a race.

Verification

  • The ordered generate-cve-json pair fails on main and passes here; the full generate-cve-json suite passed 8 of 8 parallel runs.
  • tools/adversarial-review/tests/test_runner.py passed 10 of 10 parallel runs.
  • prek run --all-files --skip workspace-pytest is clean. The commit hook's workspace-pytest passed.

Generative AI disclosure: this change was prepared with Claude Code (Opus 5.5) and reviewed by me before submission.

🤖 Generated with Claude Code

generate-cve-json: `main(["--config", ...])` reloads the module's config
globals and nothing restored them, so a test on the same xdist worker that
ran after the release-vote gating tests inherited `release_vote_gating =
true` and got DRAFT where it expected REVIEW. An autouse fixture now puts
the config back after any test that changed it. Run in that order, the two
tests failed every time before this change.

adversarial-review: two runner tests raced a wall-clock window against
stub start-up, which takes seconds on a loaded machine (the full parallel
pre-commit run). Both now use a handshake instead: the stubs wait for each
other to start, and the timeout test reports gemini's timeout only after
codex has answered. Each still fails when `run_all` runs the reviewers one
after the other.

Generated-by: Claude Code (Opus 5.5)
@github-actions github-actions Bot added family:tools tools/* contract:cve-authority Tool capability: CVE allocation / record management / publication substrate:review Tool substrate: second-model read of a change before publishing (read-only CLIs, merged findings) labels Oct 23, 2026
@potiuk
potiuk merged commit ae4d21e into apache:main Oct 23, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contract:cve-authority Tool capability: CVE allocation / record management / publication family:tools tools/* substrate:review Tool substrate: second-model read of a change before publishing (read-only CLIs, merged findings)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant