fleetd #501: readiness-grace expiry logs measured elapsed time and poll counter #503

2026-09-12T04:58:33+02:00

agent commented

2026-09-12 04:58:33 +02:00

Fixes two defects in the CB-114 readiness-grace expiry log at Injector.java:383-387 (both numbers read as measurements but were compile-time constants):

The poll count printed READINESS_GRACE_POLLS instead of the loop's own Target.notReadySincePoll counter, which was already in scope. Fixed to print the counter. Honest caveat, in a comment and in the PR: on this branch the counter has just reached the threshold, so it equals the constant by construction, and no test can tell the two apart.
The elapsed-time figure was READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS / 1000 -- arithmetic on two constants, never a measurement, and wrong in the direction that says everything ran on schedule. Fixed by adding a new Target.notReadySinceMillis field (stamped at the first non-ready sample, reset at all three sites notReadySincePoll already resets) and an injected java.util.function.LongSupplier nowMillis (default System::currentTimeMillis via new package-private constructor overloads), copying the shape LeadRollover already uses (fleetd #494/#480).

The log now reads: "readiness grace for {target} expired after {measured polls} polls (configured={N} polls/{N}s elapsed={measured}ms): ..."

Tests

Added two tests to InjectorTest using the existing ListAppender log-capture pattern:

readinessGraceExpiryLogsTheMeasuredPollCountNextToTheConfiguredBudget -- pins the message shape with plain literals (240, 60), not derived from the production constants.
readinessGraceExpiryLogsTheMeasuredElapsedTimeNotArithmeticOnConstants -- drives the loop with a stub clock returning two fixed values (1000ms, 318412ms) whose difference (317412ms) does NOT equal READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS (60000ms), so the test can fail if the fix regresses to the constant-arithmetic line.

Mutation-testing proof (see full detail in the fleet_reply handoff)

Baseline (fixed file, unmutated): 34/34 InjectorTest tests pass.
Mutation reverting the elapsed calculation back to the constant arithmetic: 1 failure (readinessGraceExpiryLogsTheMeasuredElapsedTimeNotArithmeticOnConstants), a genuine AssertionFailedError.
Mutation reverting the poll-count print back to the constant: 0 failures -- an equivalent mutant, reported as such rather than claimed as a kill (the counter and the constant are identical at that exact call site by construction).
Restored file; shasum -a 256 matched the pristine value both times.
Harness-proof: deliberately broke the elapsed-time assertion's expected literal, confirmed the suite went red and named the exact test, then restored (shasum matched again).

Build

fleetd/: mvn clean install -- Tests run: 1683, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS. No new compiler warnings; the one pre-existing deprecation warning is in FleetConfig.java, untouched by this change.

Grep proof that all three notReadySincePoll reset sites (pre-fix line numbers :304, :355, :389) now also reset the new notReadySinceMillis field is in the fleet_reply handoff.

Fixes two defects in the CB-114 readiness-grace expiry log at Injector.java:383-387 (both numbers read as measurements but were compile-time constants): 1. The poll count printed READINESS_GRACE_POLLS instead of the loop's own Target.notReadySincePoll counter, which was already in scope. Fixed to print the counter. Honest caveat, in a comment and in the PR: on this branch the counter has just reached the threshold, so it equals the constant by construction, and no test can tell the two apart. 2. The elapsed-time figure was READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS / 1000 -- arithmetic on two constants, never a measurement, and wrong in the direction that says everything ran on schedule. Fixed by adding a new Target.notReadySinceMillis field (stamped at the first non-ready sample, reset at all three sites notReadySincePoll already resets) and an injected java.util.function.LongSupplier nowMillis (default System::currentTimeMillis via new package-private constructor overloads), copying the shape LeadRollover already uses (fleetd #494/#480). The log now reads: "readiness grace for {target} expired after {measured polls} polls (configured={N} polls/{N}s elapsed={measured}ms): ..." ### Tests Added two tests to InjectorTest using the existing ListAppender log-capture pattern: - readinessGraceExpiryLogsTheMeasuredPollCountNextToTheConfiguredBudget -- pins the message shape with plain literals (240, 60), not derived from the production constants. - readinessGraceExpiryLogsTheMeasuredElapsedTimeNotArithmeticOnConstants -- drives the loop with a stub clock returning two fixed values (1000ms, 318412ms) whose difference (317412ms) does NOT equal READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS (60000ms), so the test can fail if the fix regresses to the constant-arithmetic line. ### Mutation-testing proof (see full detail in the fleet_reply handoff) - Baseline (fixed file, unmutated): 34/34 InjectorTest tests pass. - Mutation reverting the elapsed calculation back to the constant arithmetic: 1 failure (readinessGraceExpiryLogsTheMeasuredElapsedTimeNotArithmeticOnConstants), a genuine AssertionFailedError. - Mutation reverting the poll-count print back to the constant: 0 failures -- an equivalent mutant, reported as such rather than claimed as a kill (the counter and the constant are identical at that exact call site by construction). - Restored file; shasum -a 256 matched the pristine value both times. - Harness-proof: deliberately broke the elapsed-time assertion's expected literal, confirmed the suite went red and named the exact test, then restored (shasum matched again). ### Build fleetd/: mvn clean install -- Tests run: 1683, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS. No new compiler warnings; the one pre-existing deprecation warning is in FleetConfig.java, untouched by this change. Grep proof that all three notReadySincePoll reset sites (pre-fix line numbers :304, :355, :389) now also reset the new notReadySinceMillis field is in the fleet_reply handoff.

agent added 1 commit 2026-09-12 04:58:33 +02:00

fleetd #501 : readiness-grace expiry logs measured elapsed time and the loop's own poll counter, never the configured budget

CI / contract (pull_request) Successful in 49s

Details

CI / build (pull_request) Successful in 2m2s

Details

ac351ee1de

The line at Injector.java:383-387 printed two numbers that read as measurements
but were both compile-time constants: READINESS_GRACE_POLLS for the poll count
(the loop's own Target.notReadySincePoll counter was in scope at the same call
site), and READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS / 1000 for the elapsed
time — arithmetic on two constants, never a measurement, and wrong in the
direction that says everything ran on schedule.

Fix, copying the LongSupplier-clock shape LeadRollover already uses:
- print t.notReadySincePoll instead of the constant for the poll count (the two
  agree by construction on this branch, so no test can tell them apart — the
  comment says so honestly).
- add Target.notReadySinceMillis, stamped at the first non-ready sample and
  reset at all three sites notReadySincePoll already resets (:304, :355, :389
  pre-fix line numbers), to compute a real elapsed time at expiry.
- inject a LongSupplier nowMillis (defaulting to System::currentTimeMillis)
  through new package-private constructor overloads so a test can supply a
  clock whose advance does not track POLL_INTERVAL_MILLIS.

Tests use a ListAppender to assert on the log message contents, per
LeadRolloverTest's pattern. The elapsed-time test drives the loop with a stub
clock returning two literal, non-derived values so it can fail if the fix
regresses to the constant-arithmetic line — proved by mutation: reverting the
elapsed calculation to READINESS_GRACE_POLLS * POLL_INTERVAL_MILLIS turns that
one test red (1 failure); reverting the poll-count print to the constant is an
equivalent mutant (0 failures), because the counter and the constant are
identical at that exact call site by construction.

fleetd clean install: Tests run: 1683, Failures: 0, Errors: 0, Skipped: 0.

ltms merged commit 136312fb11 into main

2026-09-12 05:07:36 +02:00

ltms referenced this pull request

2026-09-12 05:11:19 +02:00

Injector's readiness-grace warn prints the configured budget as if it were elapsed time — #494's defect, in the delivery loop #501

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fleet/fleetd#503