fleetd #509: pin the pane-scan completeness fold; harden legacyPrincipal #515

Merged
ltms merged 1 commits from worker/509-4912f4-2 into main 2026-09-12 06:06:13 +02:00
Member

Closes fleetd #509.

Unit 1 — Added a PaneLocatorTest case (anEarlierClientsErrorSurvivesALaterClientsCleanNegative) that constructs a two-client PaneLocator where the lead client errors on the pane that would have owned the pid (incomplete, negative scan) and the member client cleanly reports no panes (complete, negative scan). The real fold at PaneLocator.java:117 (complete = complete && outcome.complete();) ANDs both into false; a mutant that keeps only the last client's outcome (complete = outcome.complete();) reads it as true. Verified: with the mutant applied, the new test fails with expected: <false> but was: <true>; the file was restored byte-identical (sha256 unchanged before/after); control run afterwards is green.

Unit 2 — FleetMcp.legacyPrincipal's else-branch returned Principal.primary for any caller the connection did not resolve to a worker pane, with none of CallerResolver.java:254's isLoopback/scanComplete guards. Measured: no production caller passes callers == null (Fleetd.java:696 always builds a real CallerResolver), but FleetMcpAuthzTest.mcp(false) legitimately does, for its documented "legacy constructor leaves the gate open" test — so this is a supported legacy mode, not dead code (rules out option a). Took option (b): changed the else-branch to Principal.anonymous(), widened legacyPrincipal to package-private (mirroring denyFor's precedent) so a new test (legacyPrincipalIsAnonymousNotPrimaryForAnUnresolvedCaller) pins it directly.

Build: mvn -f fleetd/pom.xml clean install — Tests run: 1696, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS.

Nothing outside the assigned scope was touched. Not run: IDE diagnostics (no IDE MCP mount available to this worker).

Closes fleetd #509. **Unit 1** — Added a PaneLocatorTest case (`anEarlierClientsErrorSurvivesALaterClientsCleanNegative`) that constructs a two-client PaneLocator where the lead client errors on the pane that would have owned the pid (incomplete, negative scan) and the member client cleanly reports no panes (complete, negative scan). The real fold at PaneLocator.java:117 (`complete = complete && outcome.complete();`) ANDs both into false; a mutant that keeps only the last client's outcome (`complete = outcome.complete();`) reads it as true. Verified: with the mutant applied, the new test fails with `expected: <false> but was: <true>`; the file was restored byte-identical (sha256 unchanged before/after); control run afterwards is green. **Unit 2** — `FleetMcp.legacyPrincipal`'s else-branch returned `Principal.primary` for any caller the connection did not resolve to a worker pane, with none of `CallerResolver.java:254`'s `isLoopback`/`scanComplete` guards. Measured: no production caller passes `callers == null` (Fleetd.java:696 always builds a real CallerResolver), but `FleetMcpAuthzTest.mcp(false)` legitimately does, for its documented "legacy constructor leaves the gate open" test — so this is a supported legacy mode, not dead code (rules out option a). Took option (b): changed the else-branch to `Principal.anonymous()`, widened `legacyPrincipal` to package-private (mirroring `denyFor`'s precedent) so a new test (`legacyPrincipalIsAnonymousNotPrimaryForAnUnresolvedCaller`) pins it directly. **Build**: `mvn -f fleetd/pom.xml clean install` — Tests run: 1696, Failures: 0, Errors: 0, Skipped: 0. BUILD SUCCESS. Nothing outside the assigned scope was touched. Not run: IDE diagnostics (no IDE MCP mount available to this worker).
agent added 1 commit 2026-09-12 05:58:38 +02:00
fleetd #509: pin the pane-scan completeness fold, and stop legacyPrincipal handing out primary
CI / contract (pull_request) Successful in 57s
CI / build (pull_request) Successful in 1m40s
32408d1e64
Unit 1 — PaneLocator.terminalForPid's completeness fold across herdr
clients (PaneLocator.java:117) had no test that varied the number of
clients, so a mutation that keeps only the last client's Lookup.complete()
instead of ANDing every client's outcome survived: 14 of 15 existing tests
agree with the mutant on a single client. Added a two-client test where
the lead client errors on the pane that would have owned the pid (an
incomplete, negative scan) and the member client cleanly finds no panes
(a complete, negative scan) — the real fold ANDs these to false, a
last-wins fold reads it as true. Proved against MUTANTC
(complete = outcome.complete();): the new test fails with
"expected: <false> but was: <true>", the file was restored byte-identical
(sha256 unchanged), and the control run is green.

Unit 2 — FleetMcp.legacyPrincipal's else-branch returned Principal.primary
for ANY caller the connection did not resolve to a worker pane, with none
of CallerResolver.java:254's isLoopback/scanComplete guards. Measured that
no production caller passes null callers (Fleetd.java:696 always
constructs a real CallerResolver) but FleetMcpAuthzTest.mcp(false)
legitimately does, for its "legacy constructor leaves the gate open" test
— so the null-callers path is not dead code to delete (option a), it is a
documented legacy mode (option b). Changed the else-branch to
Principal.anonymous() and widened legacyPrincipal to package-private (like
denyFor) so a new test pins the behavior directly, since it only ever ran
inside a contextExtractor closure no existing test triggers.
ltms merged commit 8f02576df6 into main 2026-09-12 06:06:13 +02:00
Sign in to join this conversation.