test_at_least_one_replica_is_up
test_R12_depth2_two_constraints.py · failed in 20% of captured runs
Forcing read_secondary before set_secondary failed 60% of the time — necessary but not sufficient. This race needs at least two scheduling constraints; the minimal sufficient set was not found within budget, so no patch was generated.
Where the two runs diverge
The same test, twice, on a shared time axis. The outlined pair is the ordering that differs.
Outlined: read_secondary#0 starts before set_secondary#0 in the failing run, and after it when the test passes.
set_secondary, set_primary never started in the failing run. The run flushed its spans normally, so that absence is evidence: the operation had not happened by the time the assertion read the state.
Evidence
Suspicion comes from comparing runs. The decision comes from forcing the ordering and seeing what happens.
| Ordering | Suspiciousness | When forced | Verdict |
|---|---|---|---|
| read_secondary#0 → set_secondary#0the assertion depends on this | 0.71 | fails 60% | reproduces it sometimes — necessary, but not on its own |
| read_primary#0 → set_primary#0the assertion depends on this | 0.53 | fails 40% | reproduces it sometimes — necessary, but not on its own |
No single ordering reproduces this failure on its own, so it needs at least two scheduling constraints at once. ChronoTrace reports that rather than patching the nearest symptom.
Policy gate
Every check the proposed patch had to pass before it was allowed to run.
No patch was proposed, so there was nothing for the policy gate to review.
Verification
What was established, and at which strength. A weaker check is never presented as proof.
Verification did not run: no patch reached it.