fleetd #612 r5: pin FleetdAssembly's leadConfigDirSource call site #643

2026-10-02T04:02:34+02:00

agent commented

2026-10-02 04:02:34 +02:00

Ticket: fleetd #612, Shape A, unit r5.

Scope: one call site, FleetdAssembly.java:488 -- Fleetd.leadConfigDirSource(() -> config.get().profiles(), leaders) passed into FleetMcp. This is the literal fleetd #602/#606 defect, one call site away from its own fix: FleetdLeadConfigDirSourceWiringTest already pins the factory Fleetd.leadConfigDirSource itself, but by its own javadoc cannot cover whether FleetdAssembly's call site still calls it -- swapping that one line for a bare FleetMcp.LeadConfigDirSource.none() compiled clean and left the whole suite green before this PR.

Adds one new test file, FleetdLeadConfigDirSourceAssemblyTest: assembles the real FleetdRuntime via FleetdAssembly.assembleAndStart, pulls the leadConfigDirs field off the real, assembled FleetMcp via reflection (no public accessor exists for it, unlike quarantineSource()/leadSeatSource()), and asserts it resolves a configured lead's real configDir rather than none()'s hardcoded null.

No production code changed.

Verification performed:

Loud control: flipped the expected value in the assertion, ran, confirmed RED (expected: <LOUD-CONTROL-WRONG-VALUE> but was: </mnt/fake-lead-configdir>), reverted, confirmed green.
Mutation (i), inert: replaced the call site with FleetMcp.LeadConfigDirSource.none() -> RED (expected: </mnt/fake-lead-configdir> but was: <null>). Reverted; git diff --stat empty.
Mutation (ii), mis-wire: kept Fleetd.leadConfigDirSource(...) called with every symbol in place, swapped the profile supplier for () -> Map.of() (empty map) -> RED, same assertion, same failure shape. Reverted; git diff --stat empty.
Both mutations re-anchored with grep -n before mutating (anchor count 1 each time) and after reverting.
Teardown: runtime.close() in a finally block (Surefire runs one JVM fork here).
Final gate: mvn clean install in this worktree -- Tests run: 1893, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS.

Scope note (not fixed, per ticket instructions): ticket #612's newest comment lists several other call sites in FleetdAssembly whose inert variant is a published X.none() not distinguished by any test (ranks 4, 9, 10, 11, 12) -- those are other Shape A units running in parallel, out of scope here.

Ticket: fleetd #612, Shape A, unit r5. Scope: one call site, `FleetdAssembly.java:488` -- `Fleetd.leadConfigDirSource(() -> config.get().profiles(), leaders)` passed into `FleetMcp`. This is the literal fleetd #602/#606 defect, one call site away from its own fix: `FleetdLeadConfigDirSourceWiringTest` already pins the factory `Fleetd.leadConfigDirSource` itself, but by its own javadoc cannot cover whether `FleetdAssembly`'s call site still calls it -- swapping that one line for a bare `FleetMcp.LeadConfigDirSource.none()` compiled clean and left the whole suite green before this PR. Adds one new test file, `FleetdLeadConfigDirSourceAssemblyTest`: assembles the real `FleetdRuntime` via `FleetdAssembly.assembleAndStart`, pulls the `leadConfigDirs` field off the real, assembled `FleetMcp` via reflection (no public accessor exists for it, unlike `quarantineSource()`/`leadSeatSource()`), and asserts it resolves a configured lead's real `configDir` rather than `none()`'s hardcoded null. No production code changed. **Verification performed:** - Loud control: flipped the expected value in the assertion, ran, confirmed RED (`expected: <LOUD-CONTROL-WRONG-VALUE> but was: </mnt/fake-lead-configdir>`), reverted, confirmed green. - Mutation (i), inert: replaced the call site with `FleetMcp.LeadConfigDirSource.none()` -> RED (`expected: </mnt/fake-lead-configdir> but was: <null>`). Reverted; `git diff --stat` empty. - Mutation (ii), mis-wire: kept `Fleetd.leadConfigDirSource(...)` called with every symbol in place, swapped the profile supplier for `() -> Map.of()` (empty map) -> RED, same assertion, same failure shape. Reverted; `git diff --stat` empty. - Both mutations re-anchored with `grep -n` before mutating (anchor count 1 each time) and after reverting. - Teardown: `runtime.close()` in a `finally` block (Surefire runs one JVM fork here). - Final gate: `mvn clean install` in this worktree -- `Tests run: 1893, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS`. **Scope note (not fixed, per ticket instructions):** ticket #612's newest comment lists several other call sites in `FleetdAssembly` whose inert variant is a published `X.none()` not distinguished by any test (ranks 4, 9, 10, 11, 12) -- those are other Shape A units running in parallel, out of scope here.

agent added 1 commit 2026-10-02 04:02:34 +02:00

fleetd #612 Shape A r5: pin FleetdAssembly's leadConfigDirSource call site

CI / shell-tests (pull_request) Failing after 11s

Details

CI / contract (pull_request) Successful in 1m0s

Details

CI / build (pull_request) Failing after 2m4s

Details

8c14ed2846

FleetdLeadConfigDirSourceWiringTest already pins Fleetd.leadConfigDirSource
itself, but by its own javadoc cannot cover whether FleetdAssembly.java:488
still calls it -- that call site could be swapped for a bare
FleetMcp.LeadConfigDirSource.none() (the literal fleetd #602/#606 defect)
and the whole suite would stay green.

Add FleetdLeadConfigDirSourceAssemblyTest: assembles the real FleetdRuntime
via FleetdAssembly.assembleAndStart, reads the leadConfigDirs field off the
real FleetMcp via reflection (no public accessor exists), and asserts it
resolves a configured lead's real configDir rather than none()'s hardcoded
null.

Verified: loud control (flip expected value) goes RED, reverts green;
mutation (i) inert none() at the call site goes RED; mutation (ii) mis-wire
(empty profile map, symbols otherwise intact) goes RED; both mutations
revert to an empty git diff. Full mvn clean install: 1893 tests, 0
failures, 0 errors, BUILD SUCCESS.

ltms merged commit dac5f88812 into main

2026-10-02 04:05:50 +02:00

ltms referenced this pull request

2026-10-02 04:58:34 +02:00

Fleetd.main's injected wirings are unpinned: 16 call sites go inert with a fully green suite #612

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fleet/fleetd#643