Two more fixes on the same line, LeadRollover.java:600-624:
1. The poll-count argument (second, was PICKUP_GRACE_POLLS) now prints the
loop's own idlePollsAwaitingPickup counter instead of the constant. Same
defect shape as the nudges fix from c87cc25, one argument over.
2. LeadRolloverTest's clearGraceReleaseLogIsWarnWithMeasuredElapsed asserted
its nudge-count expectation as `LeadRollover.PICKUP_GRACE_POLLS - 1` — the
same expression the production code used to build the log line from, so it
could not discriminate a reverted fix. Rewritten to plain literals
("after 8 consecutive IDLE/DONE polls (7 of those were nudged)"), proven to
trip when PICKUP_GRACE_POLLS's value changes (2 failures under a
PICKUP_GRACE_POLLS=5 mutation: this test and successLogPrintsMeasured...).
Also corrected the comment above the log line: idlePollsAwaitingPickup and
nudges each have exactly one write site on this loop's release branch, so they
cannot differ from PICKUP_GRACE_POLLS / PICKUP_GRACE_POLLS - 1 at this call
site — confirmed by re-deriving the loop's control flow, and by reverting just
the nudges argument (M1) and observing 33/0 stayed green even after the test
rewrite. That is an equivalent mutant on this line, not a gap the test rewrite
could close; the honest value of printing the counters is one source of truth
for the loop, not a provable-by-test difference here. The place nudges truly
varies with the run — and is covered by a test that can tell it apart from a
constant — is the /clear-timeout warn's clearResult.nudges() in runRollover.
mvn -Dtest=LeadRolloverTest test: 33/0. mvn clean install: 1681/0, BUILD SUCCESS.
Same-shape sweep (found, not fixed, per instructions):
Injector.java:383-387 — the readiness-grace warn prints the constant
READINESS_GRACE_POLLS where the measured per-target counter
t.notReadySincePoll is in scope (single increment site, just reached the
threshold at this call site — same equivalent-mutant situation as this fix).
- waitForClearPickupAndSettle's grace-release warn now prints the measured 'nudges' counter
instead of the constant PICKUP_GRACE_POLLS - 1. The two happen to agree today, but the
constant expression was wrong once before (printed PICKUP_GRACE_POLLS itself, claiming 8
nudges where 7 went out) and a code read did not catch it — only a mutation test did.
Printing the counter cannot drift from the loop's real behaviour.
- waitUntilAtTurnBoundary (the FIRST wait, ~line 386-391) had the identical 'configured value
printed as if measured' defect as the three lines fixed in the original #494 commit, but was
out of scope because the brief named specific lines instead of the shape. Fixed the same way:
it now returns a TurnSettleResult(settled, elapsedMillis) instead of a bare boolean, and the
timeout warn prints 'configured={}s elapsed={}ms' instead of presenting cfg.turnSettleSeconds()
as the measured wait.
- No behaviour change: same sends, same order, same release/refuse decisions.
- Test additions: clearGraceReleaseLogIsWarnWithMeasuredElapsed now also asserts the measured
nudge count; successLogPrintsMeasuredElapsedForTheWholeRoll's expected elapsed value is
updated (7000ms, not 6500ms) to account for waitUntilAtTurnBoundary's own new clock read; a
new turnTimeoutLogPrintsMeasuredElapsedNotJustConfigured test pins the sibling line.
- Proved the nudges fix with a temporary mutation: set PICKUP_GRACE_POLLS to 5, confirmed via
two greps that the mutant applied and the original constant was gone, ran the grace-release
test and read the actual log line — nudge count followed to 4 (= 5 - 1), then restored to 8
and reran the full LeadRolloverTest suite as a control (33/33 green).
- runRollover's /clear-timeout warn now prints configured/elapsed/nudges, each labelled,
instead of presenting cfg.clearSettleSeconds() as if it were the measured wait.
- waitForClearPickupAndSettle's pickup-grace release is now log.warn (was log.info) and
prints the measured elapsed time next to the target pane — this is the exact path that
reported a false-success roll in the real incident (438ms of a 20s budget).
- The success line ('lead-rollover: rolled') now prints the measured elapsed time for the
whole roll.
- waitForClearPickupAndSettle now returns a ClearSettleResult(settled, elapsedMillis, nudges)
instead of a bare boolean, so callers can log the measured values instead of the config.
- No behaviour change: same sends, same order, same release/refuse decisions.
- Adds 3 tests to LeadRolloverTest pinning the content of each changed log line, using a
self-advancing fake clock so the measured elapsed/nudge values are deterministic and
provably distinct from the configured budget.
Dai Ha