fleet/fleetd
3
0
Fork 0
Code Issues 78 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fleetd #612 Shape A r9+r11: pin capacitySource, healthCoverageSource, coordinator.peers #647

Closed
agent wants to merge 1 commits from worker/612-a-r9-r11-capacity-coverage-peers-cfcc79-7 into main
pull from: worker/612-a-r9-r11-capacity-coverage-peers-cfcc79-7
merge into: fleet:main
Conversation 1 Commits 1 Files Changed 2
+373

1 Commits

Author SHA1 Message Date
Dai Ha dd28dab0f2 fleetd #612 Shape A r9+r11: pin capacitySource, healthCoverageSource, coordinator.peers at the assembly call site
CI / shell-tests (pull_request) Failing after 10s
Details
CI / contract (pull_request) Successful in 1m18s
Details
CI / build (pull_request) Failing after 2m0s
Details 
FleetdAssembly's new FleetMcp(...) call wires three sources at :481/:482/:489 that no test
drove through the real assembly before: Fleetd.capacitySource, Fleetd.healthCoverageSource,
and the cfg.coordinator() == null ? List.of() : cfg.coordinator().peers() ternary. The two
factory methods already had isolated unit tests (FleetdCapacitySourceWiringTest,
FleetdHealthCoverageSourceWiringTest), but neither proved FleetdAssembly's constructor call
actually receives their output rather than an inert stand-in or an unrelated config ref.

FleetdCapacityHealthCoveragePeersAssemblyTest drives the real FleetdAssembly.assembleAndStart
and reads each source straight off the real FleetMcp FleetdRuntime.mcp() owns. That needed
three small, read-only public accessors on FleetMcp (capacitySource(), healthCoverageSource(),
coordinatorPeers()) — the same cross-package shape quarantineSource()/leadSeatSource()/
leadRollover() already use (fleetd #612 B3), added because driving fleet_list itself through
a real MCP/HTTP round trip is a dead end here: FleetdAssembly builds its ConnectionIdentity
with a hardcoded real LsofPeerPidLookup, which excludes its own pid, so a same-JVM test
caller always resolves ANONYMOUS and never reaches fleet_list's READ gate
(FleetdAssemblyFleetAppTest's own javadoc documents this exact dead end for GET /sessions).

Each of the three assertions was verified independently: a loud control (flip the expected
value, observe RED, revert) plus two full-suite mutation cycles per site (inert stand-in,
then a mis-wire that keeps every call-site symbol and only swaps the collaborator identity) —
each mutation failed exactly the one named test and left the other two green, then was
reverted clean. Full suite: mvn clean install, Tests run: 1895, Failures: 0, Errors: 0,
Skipped: 0, BUILD SUCCESS.
 2026-10-02 04:20:21 +02:00