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

fleetd #672: pin AuthorizationMode.ENFORCED at FleetdAssembly.java:481 #673

Closed
agent wants to merge 0 commits from worker/672-0f2469-2 into main
pull from: worker/672-0f2469-2
merge into: fleet:main
Conversation 0 Commits - Files Changed -
agent commented 2026-10-03 20:43:58 +02:00
Member
Copy Link
Copy Source

Pins the FleetMcp.AuthorizationMode that production passes at FleetdAssembly.java:481 (AuthorizationMode.ENFORCED). Fixes fleetd #672.

Before this, nothing observed that call site: FleetMcpAuthzTest builds its own FleetMcp and picks its own mode, so it tests the seam, not the producer. Flipping line 481 to UNENFORCED left all 1928 tests on main green.

What this adds

FleetdAssemblyAuthorizationModeTest drives the real FleetMcp that FleetdAssembly#assembleAndStart builds (via FleetdRuntime#mcp(), same accessor FleetdAssemblyConnectionIdentityTest uses for identity()), and asserts the consequence rather than reading the enum back: a worker is refused SPAWN through it, and the primary is still allowed (the loud control so the test cannot pass with the gate wired backwards).

FleetMcp#denyFor is package-private to dev.ltms.fleet.mcp; this test lives in dev.ltms.fleet (where FleetdAssembly/FleetdRuntime live), so it reaches denyFor by reflection to cross that package boundary — the assertion itself still exercises the real policy decision (denyFor calling Authz.permits), not a field read. No catch swallows a missing method; a NoSuchMethodException would fail the test loudly.

Verification (in a throwaway worktree, never the main clone)

  • Green: mvn clean install → Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS.
  • Mutant: perl -i -pe 's/AuthorizationMode\.ENFORCED/AuthorizationMode.UNENFORCED/ if $. == 481' fleetd/src/main/java/dev/ltms/fleet/FleetdAssembly.java → git diff --numstat showed exactly 1 line in 1 file → mvn clean install → exit 1, Tests run: 1929, Failures: 1, Errors: 0, Skipped: 0. The one failure was FleetdAssemblyAuthorizationModeTest.productionBootPathRefusesAnUnauthorizedCallerThroughTheAssembledFleetMcp; grepping the full log for <<< FAILURE / <<< ERROR found no other test.
  • Reverted line 481, confirmed git status --porcelain shows only the new test file, then green again: Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS.

Sweep (report only, per the ticket — nothing else changed)

Went through every constructor argument in FleetdAssembly for a hardcoded constant encoding a real decision, ranked by blast radius:

  1. FleetdAssembly.java:481 AuthorizationMode.ENFORCED — now pinned by this PR.
  2. FleetdAssembly.java:265 Set.of() (excludedWorkspaceLabels) — already pinned in #671/#670.
  3. FleetdAssembly.java:376-377 — 5 reminders / 15_000L backoffMs, the fallback ReplyPushLoop gets when cfg.primary() is entirely absent. No test observes these two literals reaching the real assembled ReplyPushLoop: FleetdAssemblyReleaseCleanupBehaviouralTest only reaches in for the primaryRegistry field, and FleetdBackendErrorSinkTest builds its own ReplyPushLoop with its own literals (3, 50) — the same seam-not-producer blind spot this ticket is about. If wrong, a daemon booted with no primary: block silently nudges (or stops nudging) the primary at the wrong cadence.
  4. FleetdAssembly.java:118/:499 LEAD_COORD_INTERVAL_MS = 3_000L — how often LeadCoordLoop polls the shared coordination broker for peer-lead mail. FleetdAssemblyCoordinatorLifecycleTest only checks that LeadCoordLoop is constructed (non-null), never the interval. If wrong, cross-daemon lead coordination degrades silently.
  5. FleetdAssembly.java:350 Injector.POLL_INTERVAL_MILLIS passed to StatusPoller — the constant itself is well covered where it's declared (Injector/InjectorTest), but no assembly-level test pins that this exact constant (vs. some other value) is what reaches the real StatusPoller. Lower priority: a gross error here would surface quickly as fleet-wide delivery lag, unlike the silent authz gap.
  6. FleetdAssembly.java:490 cfg.coordinator() == null ? List.of() : cfg.coordinator().peers() — the only sane default for "no coordinator block"; FleetMcp's own constructor already null-safes peers (peers == null ? List.of() : List.copyOf(peers)), so a wrong value here has nowhere to do damage. Negligible.

Checked and ruled out as already covered: FleetHealthMonitor.coverage(true, …) at :431 (the true is inside the branch that already requires it true, not an independent decision); CallerResolver.withLeadsAndMembers(identity, true/false, …) at :464/:468 (both branches are driven behaviorally against the real assembly by FleetdQuarantineOutageDualWindowAssemblyTest/FleetdListReportingSourcesAssemblyTest, per FleetdAssemblyFleetAppTest's own javadoc); new PaneLocator(herdr, memberHerdr) at :453 (argument order already pinned by FleetdAssemblyConnectionIdentityTest).

Constraints followed

  • FleetdAssembly.java:481 itself is unchanged — ENFORCED stays, only a test was added.
  • Built only in this worktree, never the main clone.
  • wiki/ sync check not run — wiki/ is uninitialized in this worktree; not reported as passed.
Pins the `FleetMcp.AuthorizationMode` that production passes at `FleetdAssembly.java:481` (`AuthorizationMode.ENFORCED`). Fixes fleetd #672. Before this, nothing observed that call site: `FleetMcpAuthzTest` builds its own `FleetMcp` and picks its own mode, so it tests the seam, not the producer. Flipping line 481 to `UNENFORCED` left all 1928 tests on `main` green. ## What this adds `FleetdAssemblyAuthorizationModeTest` drives the real `FleetMcp` that `FleetdAssembly#assembleAndStart` builds (via `FleetdRuntime#mcp()`, same accessor `FleetdAssemblyConnectionIdentityTest` uses for `identity()`), and asserts the consequence rather than reading the enum back: a worker is refused `SPAWN` through it, and the primary is still allowed (the loud control so the test cannot pass with the gate wired backwards). `FleetMcp#denyFor` is package-private to `dev.ltms.fleet.mcp`; this test lives in `dev.ltms.fleet` (where `FleetdAssembly`/`FleetdRuntime` live), so it reaches `denyFor` by reflection to cross that package boundary — the assertion itself still exercises the real policy decision (`denyFor` calling `Authz.permits`), not a field read. No `catch` swallows a missing method; a `NoSuchMethodException` would fail the test loudly. ## Verification (in a throwaway worktree, never the main clone) - Green: `mvn clean install` → `Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS`. - Mutant: `perl -i -pe 's/AuthorizationMode\.ENFORCED/AuthorizationMode.UNENFORCED/ if $. == 481' fleetd/src/main/java/dev/ltms/fleet/FleetdAssembly.java` → `git diff --numstat` showed exactly 1 line in 1 file → `mvn clean install` → exit 1, `Tests run: 1929, Failures: 1, Errors: 0, Skipped: 0`. The one failure was `FleetdAssemblyAuthorizationModeTest.productionBootPathRefusesAnUnauthorizedCallerThroughTheAssembledFleetMcp`; grepping the full log for `<<< FAILURE` / `<<< ERROR` found no other test. - Reverted line 481, confirmed `git status --porcelain` shows only the new test file, then green again: `Tests run: 1929, Failures: 0, Errors: 0, Skipped: 0`, `BUILD SUCCESS`. ## Sweep (report only, per the ticket — nothing else changed) Went through every constructor argument in `FleetdAssembly` for a hardcoded constant encoding a real decision, ranked by blast radius: 1. `FleetdAssembly.java:481` `AuthorizationMode.ENFORCED` — now pinned by this PR. 2. `FleetdAssembly.java:265` `Set.of()` (`excludedWorkspaceLabels`) — already pinned in #671/#670. 3. `FleetdAssembly.java:376-377` — `5` reminders / `15_000L` backoffMs, the fallback `ReplyPushLoop` gets when `cfg.primary()` is entirely absent. No test observes these two literals reaching the real assembled `ReplyPushLoop`: `FleetdAssemblyReleaseCleanupBehaviouralTest` only reaches in for the `primaryRegistry` field, and `FleetdBackendErrorSinkTest` builds its own `ReplyPushLoop` with its own literals (3, 50) — the same seam-not-producer blind spot this ticket is about. If wrong, a daemon booted with no `primary:` block silently nudges (or stops nudging) the primary at the wrong cadence. 4. `FleetdAssembly.java:118`/`:499` `LEAD_COORD_INTERVAL_MS = 3_000L` — how often `LeadCoordLoop` polls the shared coordination broker for peer-lead mail. `FleetdAssemblyCoordinatorLifecycleTest` only checks that `LeadCoordLoop` is constructed (non-null), never the interval. If wrong, cross-daemon lead coordination degrades silently. 5. `FleetdAssembly.java:350` `Injector.POLL_INTERVAL_MILLIS` passed to `StatusPoller` — the constant itself is well covered where it's declared (`Injector`/`InjectorTest`), but no assembly-level test pins that this exact constant (vs. some other value) is what reaches the real `StatusPoller`. Lower priority: a gross error here would surface quickly as fleet-wide delivery lag, unlike the silent authz gap. 6. `FleetdAssembly.java:490` `cfg.coordinator() == null ? List.of() : cfg.coordinator().peers()` — the only sane default for "no coordinator block"; `FleetMcp`'s own constructor already null-safes `peers` (`peers == null ? List.of() : List.copyOf(peers)`), so a wrong value here has nowhere to do damage. Negligible. Checked and ruled out as already covered: `FleetHealthMonitor.coverage(true, …)` at :431 (the `true` is inside the branch that already requires it true, not an independent decision); `CallerResolver.withLeadsAndMembers(identity, true/false, …)` at :464/:468 (both branches are driven behaviorally against the real assembly by `FleetdQuarantineOutageDualWindowAssemblyTest`/`FleetdListReportingSourcesAssemblyTest`, per `FleetdAssemblyFleetAppTest`'s own javadoc); `new PaneLocator(herdr, memberHerdr)` at :453 (argument order already pinned by `FleetdAssemblyConnectionIdentityTest`). ## Constraints followed - `FleetdAssembly.java:481` itself is unchanged — `ENFORCED` stays, only a test was added. - Built only in this worktree, never the main clone. - `wiki/` sync check not run — `wiki/` is uninitialized in this worktree; not reported as passed.
agent added 1 commit 2026-10-03 20:43:58 +02:00
fleetd #672: pin AuthorizationMode.ENFORCED at FleetdAssembly.java:481
CI / shell-tests (pull_request) Failing after 6s
Details
CI / contract (pull_request) Successful in 1m6s
Details
CI / build (pull_request) Failing after 1m41s
Details
367facf6a6 
Adds FleetdAssemblyAuthorizationModeTest: drives FleetMcp#denyFor (via reflection, since it is package-private to dev.ltms.fleet.mcp) on the real FleetMcp FleetdAssembly#assembleAndStart builds, asserting an unauthorized worker is refused SPAWN and the primary is still allowed. Mutating line 481 to UNENFORCED turns this test red and no other test.
ltms closed this pull request 2026-10-03 20:53:58 +02:00
Some checks are pending
CI / shell-tests (pull_request) Failing after 6s
Details
CI / contract (pull_request) Successful in 1m6s
Details
CI / build (pull_request) Failing after 1m41s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#673
Delete Branch "worker/672-0f2469-2"

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?