fleetd #426: pin FleetHealthMonitor.coverage and its HealthCoverageSource call site #542

2026-09-12T08:44:38+02:00

agent commented

2026-09-12 08:44:38 +02:00

fleetd #426: FleetHealthMonitor.coverage had zero references in the test tree — not the method, not either output string, not the field it populates. Three independent mutations (inverting enabled, swapping the two output strings, breaking the argument pairing at the HealthCoverageSource call site in Fleetd.java) all shipped a green build.

What changed

Extracted the inline HealthCoverageSource lambda in Fleetd.main into a package-private static factory Fleetd.healthCoverageSource(ConfigRef) — same shape as the existing capacitySource/quarantineSource factories, which exist for the identical argument-pairing risk (fleetd #415).
Added FleetHealthMonitorCoverageTest — pins the three-branch method directly (the easy half).
Added FleetdHealthCoverageSourceWiringTest — the half that matters: drives the extracted factory with a real FleetConfig.load + ConfigRef against @TempDir YAML fixtures (off / detection-only / full / absent health block), plus a hot-reload case proving health.notifications stays live.

Why extraction (a new seam) instead of #407's option 1

#407 (five log-only reporters) prefers keeping the config invalid and asserting on the log line emitted before cfg.validateAll() throws — that adds no production code. That does not apply here: this call site is built during FleetMcp construction, well after validateAll() (~line 171) and after UnixSocketHerdrClient.connect has already opened a real herdr socket (~line 188). Reaching it via a real Fleetd.main run would require real socket I/O, which this ticket's tests must not do. So the pairing is pinned by extraction instead, following the codebase's own established precedent for this exact defect shape.

Output strings unchanged

"off" / "detection-only" / "full" are untouched — "detection-only" is what a live daemon's fleet_list reports today.

Verification

mvn clean install: Tests run: 1709, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS (baseline on f1640f5 was 1701; +8 new tests: 5 wiring + 3 method-level).
Mutation 1 (invert enabled): all 8 new tests fail. Killed.
Mutation 2 (swap "full"/"detection-only"): 5 of 8 fail (the 3 off-only tests correctly stay green). Killed.
Mutation 3 (break argument pairing at the HealthCoverageSource call site): 3 of 5 wiring tests fail — the 2 that pass do so because their fixtures use symmetric booleans (both true, or both false/null) where swapping coincidentally yields the same output; the mixed-boolean cases catch the real defect. Killed.
Each mutation verified landed via grep count against a saved pristine copy (not a symmetric pattern), and restored with full shasum -a 256 before/after equality plus clean git status.
No mutation survived, so no separate false-assertion harness proof was needed (a kill is its own proof per the ticket).

Ticket: fleetd #426.

fleetd #426: FleetHealthMonitor.coverage had zero references in the test tree — not the method, not either output string, not the field it populates. Three independent mutations (inverting `enabled`, swapping the two output strings, breaking the argument pairing at the `HealthCoverageSource` call site in Fleetd.java) all shipped a green build. ## What changed - Extracted the inline `HealthCoverageSource` lambda in `Fleetd.main` into a package-private static factory `Fleetd.healthCoverageSource(ConfigRef)` — same shape as the existing `capacitySource`/`quarantineSource` factories, which exist for the identical argument-pairing risk (fleetd #415). - Added `FleetHealthMonitorCoverageTest` — pins the three-branch method directly (the easy half). - Added `FleetdHealthCoverageSourceWiringTest` — the half that matters: drives the extracted factory with a real `FleetConfig.load` + `ConfigRef` against `@TempDir` YAML fixtures (off / detection-only / full / absent health block), plus a hot-reload case proving `health.notifications` stays live. ## Why extraction (a new seam) instead of #407's option 1 #407 (five log-only reporters) prefers keeping the config invalid and asserting on the log line emitted before `cfg.validateAll()` throws — that adds no production code. That does not apply here: this call site is built during `FleetMcp` construction, well after `validateAll()` (~line 171) and after `UnixSocketHerdrClient.connect` has already opened a real herdr socket (~line 188). Reaching it via a real `Fleetd.main` run would require real socket I/O, which this ticket's tests must not do. So the pairing is pinned by extraction instead, following the codebase's own established precedent for this exact defect shape. ## Output strings unchanged `"off"` / `"detection-only"` / `"full"` are untouched — `"detection-only"` is what a live daemon's `fleet_list` reports today. ## Verification - `mvn clean install`: `Tests run: 1709, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS` (baseline on f1640f5 was 1701; +8 new tests: 5 wiring + 3 method-level). - Mutation 1 (invert `enabled`): all 8 new tests fail. Killed. - Mutation 2 (swap `"full"`/`"detection-only"`): 5 of 8 fail (the 3 `off`-only tests correctly stay green). Killed. - Mutation 3 (break argument pairing at the `HealthCoverageSource` call site): 3 of 5 wiring tests fail — the 2 that pass do so because their fixtures use symmetric booleans (both true, or both false/null) where swapping coincidentally yields the same output; the mixed-boolean cases catch the real defect. Killed. - Each mutation verified landed via grep count against a saved pristine copy (not a symmetric pattern), and restored with full `shasum -a 256` before/after equality plus clean `git status`. - No mutation survived, so no separate false-assertion harness proof was needed (a kill is its own proof per the ticket). Ticket: fleetd #426.

agent added 1 commit 2026-09-12 08:44:39 +02:00

fleetd #426 : pin FleetHealthMonitor.coverage and its HealthCoverageSource call site

CI / contract (pull_request) Successful in 48s

Details

CI / build (pull_request) Successful in 2m16s

Details

1850a5f324

FleetHealthMonitor.coverage had zero references in the test tree — not the
method, not either output string, not the field it populates. Inverting
`enabled`, swapping "full"/"detection-only", or breaking the argument pairing
at the HealthCoverageSource call site in Fleetd.java all shipped a green
build.

Extract the HealthCoverageSource lambda out of Fleetd.main into a
package-private static factory (healthCoverageSource(ConfigRef)), the same
shape capacitySource/quarantineSource already use for the identical
argument-pairing risk (fleetd #415). #407's "keep the config invalid, assert
on the log line before validateAll() throws" option does not apply here: this
call site is built well after validateAll() and after a real herdr socket
connect, so driving it through a real Fleetd.main would require the socket
I/O this ticket's tests must not do.

Add FleetHealthMonitorCoverageTest (the three-branch method itself) and
FleetdHealthCoverageSourceWiringTest (the call site, via a real
FleetConfig.load + ConfigRef against @TempDir fixtures, including a hot
notifications-reload case). Output strings are unchanged — "detection-only"
is still what a live fleet_list reports today.

Measured: all three mutations killed by the new tests.

ltms merged commit 4a8a780274 into main

2026-09-12 08:55:46 +02:00

ltms referenced this pull request

2026-09-12 08:56:04 +02:00

FleetHealthMonitor.coverage has no test at all, and it feeds fleet_list's healthCoverage field #426

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fleet/fleetd#542