fleetd #612 ranks 6/7 + #630: behavioural pins for healthFailTarget, releaseCleanup, requireOperatorConfirm #632

2026-10-01T16:30:42+02:00

agent commented

2026-10-01 16:30:42 +02:00

fleetd #612 step 4 — three of four parallel units, covering #612 ranks 6/7 plus the whole of #630.

Scope (per the brief):

FleetdAssembly.java:429 — healthFailTarget (#612 rank 7)
FleetdAssembly.java:447 — releaseCleanup (#612 rank 6)
FleetdAssembly.java:402/:409 — requireOperatorConfirm (#630, the whole ticket)

What changed: three new test files, no production code touched (git diff --stat on
FleetdAssembly.java is empty on this branch). Each test drives the real
FleetdAssembly.assembleAndStart (the real boot graph Unit A exposed) and asserts the
behavioural effect of the real, assembled object — never source text, never a hand-built
copy of the collaborators.

Mutation cycle run for every site (pristine anchor count 1 → line-anchored sed to the
inert form → compiles → new test RED → restore → green; see the hand-off message for the
full output of each cycle). requireOperatorConfirm is proven in both directions (false
and true produce genuinely different notice text from the real assembled loop).

Full suite on this branch: 1886 tests, 0 failures, 0 errors, BUILD SUCCESS
(baseline on main: 1883 + 3 new tests).

Caveat for review: the healthFailTarget and releaseCleanup tests reach a
package-private field via reflection (the same technique StatusPollerResilienceTest
already uses in this suite) because FleetHealthMonitor.failTarget and
SessionManager.releaseListeners are private with no public accessor, and the collaborator
objects themselves (the assembled MessageService, ReplyInbox, PrimaryRegistry) are
real production instances reached through FleetdRuntime's existing accessors
(messages(), replyInbox(), pushLoop()) — never rebuilt or copied.

fleetd #612 step 4 — three of four parallel units, covering #612 ranks 6/7 plus the whole of #630. **Scope (per the brief):** - `FleetdAssembly.java:429` — `healthFailTarget` (#612 rank 7) - `FleetdAssembly.java:447` — `releaseCleanup` (#612 rank 6) - `FleetdAssembly.java:402`/`:409` — `requireOperatorConfirm` (#630, the whole ticket) **What changed:** three new test files, no production code touched (`git diff --stat` on `FleetdAssembly.java` is empty on this branch). Each test drives the real `FleetdAssembly.assembleAndStart` (the real boot graph Unit A exposed) and asserts the behavioural effect of the real, assembled object — never source text, never a hand-built copy of the collaborators. **Mutation cycle run for every site** (pristine anchor count 1 → line-anchored sed to the inert form → compiles → new test RED → restore → green; see the hand-off message for the full output of each cycle). `requireOperatorConfirm` is proven in both directions (false and true produce genuinely different notice text from the real assembled loop). **Full suite on this branch:** 1886 tests, 0 failures, 0 errors, BUILD SUCCESS (baseline on main: 1883 + 3 new tests). **Caveat for review:** the `healthFailTarget` and `releaseCleanup` tests reach a package-private field via reflection (the same technique `StatusPollerResilienceTest` already uses in this suite) because `FleetHealthMonitor.failTarget` and `SessionManager.releaseListeners` are private with no public accessor, and the collaborator objects themselves (the assembled `MessageService`, `ReplyInbox`, `PrimaryRegistry`) are real production instances reached through `FleetdRuntime`'s existing accessors (`messages()`, `replyInbox()`, `pushLoop()`) — never rebuilt or copied.

agent added 1 commit 2026-10-01 16:30:43 +02:00

fleetd #612 ranks 6/7 + #630 : behavioural pins for healthFailTarget, releaseCleanup, requireOperatorConfirm

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

Details

CI / contract (pull_request) Successful in 53s

Details

CI / build (pull_request) Failing after 2m58s

Details

9dca376604

Three FleetdAssembly.java call sites had no test that drives the real
assembly and inspects what it actually built, so each could be swapped
for an inert variant and the suite would stay green:

- FleetdAssembly.java:429 (healthFailTarget, #612 rank 7): a no-op
  BiConsumer leaves a dead member's waiting ticket PENDING for the full
  30-minute async timeout instead of failing it immediately.
- FleetdAssembly.java:447 (releaseCleanup, #612 rank 6): a no-op
  onRelease listener leaks a stuck rendezvous waiter, an unreleased
  reply-inbox consumer, and a stale lead binding on every teardown.
- FleetdAssembly.java:402/:409 (requireOperatorConfirm, #630): dropping
  the 14th LeadHeartbeatLoop constructor argument selects the
  13-argument overload, which hardcodes true (fleetd #621) regardless
  of leadRollover.requireOperatorConfirm — silently reverting an
  operator's own config choice.

Each existing "wiring" test for these sites (FleetdHealthFailTargetWiringTest,
FleetdReleaseCleanupWiringTest) calls the Fleetd.* factory method directly
and never drives FleetdAssembly.assembleAndStart, so none of them can see
whether the real call site still passes the real, assembled collaborators.

The three new tests here assemble the real daemon via
FleetdAssembly.assembleAndStart, reach the real wired object (reflection,
same technique StatusPollerResilienceTest already uses — the fields and
the requireOperatorConfirm overload resolution point are package-private),
and assert the real behavioural effect against the real collaborators
FleetdRuntime exposes. Each is mutation-tested: a line-anchored sed to the
inert form compiles clean and turns the new test RED; restoring the
original line turns it GREEN again. requireOperatorConfirm is proven in
both directions (false and true produce genuinely different notice text).

Full suite: 1886 tests, 0 failures, 0 errors (baseline 1883 + 3 new).

agent referenced this issue from a commit

2026-10-01 16:49:19 +02:00

fleetd #632: tear down the three assembly behavioural tests' background loops

agent added 1 commit 2026-10-01 16:49:20 +02:00

fleetd #632 : tear down the three assembly behavioural tests' background loops

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

Details

CI / contract (pull_request) Successful in 1m6s

Details

CI / build (pull_request) Failing after 2m39s

Details

619769bb52

Each of FleetdAssemblyHealthFailTargetBehaviouralTest,
FleetdAssemblyReleaseCleanupBehaviouralTest and
FleetdAssemblyRequireOperatorConfirmBehaviouralTest called
FleetdAssembly.assembleAndStart without ever tearing it down: no close(),
no shutdownHook, no @AfterEach, no finally. Surefire runs the whole suite
in one JVM fork, so every scheduler/loop these tests started kept running
for the rest of the suite.

Capture the shutdown hook in each test's fake ResourcePorts (the existing
pattern from FleetdAssemblyLifecycleTest et al.) and run it in a finally
block, on the failure path too. RequireOperatorConfirmBehaviouralTest
assembles twice in one method, so assembleHeartbeat now returns both the
loop and its ResourcePorts so each assembly gets its own teardown.

Proof the teardown actually runs: assert ports.herdr.closed after running
the hook (FakeHerdr.close() only flips that flag from inside the real
close chain). Verified the assertion is load-bearing by temporarily
removing one shutdownHook.run() call and confirming the test then fails.

No assertion, test name or reflection changed. Diff is test-only.

ltms referenced this issue from a commit

2026-10-01 16:52:43 +02:00

Merge PR #632: fleetd #612 ranks 6+7 + #630 — behavioural pins for lifecycle wirings

ltms referenced this pull request

2026-10-01 16:57:23 +02:00

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