fleetd #612 Unit A: extract main's boot composition into FleetdAssembly/FleetdRuntime #620
Reference in New Issue
Block a user
Delete Branch "worker/fleetd-612-unita-87807e-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Unit A of fleetd #612 (see the architect proposal comment on the ticket). Fleetd.main keeps config loading, startup reports and validation; everything from the herdr socket connect onward moved verbatim, same order, into FleetdAssembly.assembleAndStart(AssemblyInputs, ResourcePorts), returning a FleetdRuntime that owns the real production objects (package-private accessors, never a copy) and their single ordered close(). ResourcePorts/SystemResourcePorts abstract every boot-time side effect (env, herdr connect, broker openers, clocks, schedulers, shutdown-hook registration, HTTP start) with deliberately no inert production variant.
sleepHerdrPoll widened from private to package-private (FleetdAssembly needs a method reference to it); no other constructor or signature changed.
FleetdAssemblyLifecycleTest drives the real assembly with FakeHerdr, a temp FleetConfig and a fake ResourcePorts recording a start/close ledger, asserted against the order recorded from the pre-move main()/shutdown hook, and proves every observable resource (herdr client, the three always-created schedulers, the AMQP reply inbox) closes via FleetdRuntime.close(). No real herdr socket, broker, or HTTP bind. FakeHerdr gained a closed flag for this.
Documented gap: the config leaves coordinator: unset, so leadMailbox/leadCoordLoop stay null and are not exercised by this test's ledger (LeadMailbox requires a real AMQP Connection even via its package-private constructor).
Build: mvn -q -o test-compile succeeded; mvn -q -o test -Dtest=FleetdAssemblyLifecycleTest passed 1/1. The full mvn clean install gate could not be run in this worktree — two identical attempts were both denied by this session's own sandbox/auto-mode classifier (reasons: "Interfere With Workloads", then "Irreversible Local Destruction"), not by the build itself. Flagging this for the lead to re-run and verify against main's current baseline.
Out of scope (per the ticket's unit split): Units B/C (ExhaustionWiring/BrokerResources/RuntimeHooks/FleetMcp.ReportingSources) and Unit D (deleting the source-text wiring tests).
Per ticket comment 17525: my second independent mutation on FleetdAssembly.java:518 survived — new FleetApp(memberHerdr, memberHerdr, ...) (dropping the LEAD client instead of the member one) left both existing FleetdAssemblyFleetAppTest cases green. That is the symmetric form of the CB-185 defect (/healthz green while the LEAD daemon is down), and the guard this PR deletes would have caught it: its positive assertion required the exact pair "new FleetApp(herdr, memberHerdr, workers,", which does not survive either daemon being dropped. Adds healthzGoesRedWhenTheLeadDaemonIsDownEvenThoughTheMemberIsUp, symmetric to the existing member-down case. Proven red today: reverting FleetdAssembly.java:518 to "new FleetApp(memberHerdr, memberHerdr, workers, ..." and running only FleetdAssemblyFleetAppTest gives Tests run: 3, Failures: 1 — the new case fails ("expected: <503> but was: <200>", body has no "member" key); the other two cases stay green. Reverted, git diff --stat empty, file touched, re-ran: Tests run: 3, Failures: 0. Full mvn -o test: Tests run: 1884, Failures: 7 (same 7 B1/B3-scope failures as before this fixup; 1884 = 1883 + 1 new case).