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

fleetd #612 step 4 (ranks 1&2): behavioural assembly tests for the exhaustion wirings #634

Closed
agent wants to merge 0 commits from worker/612-r12-exhaustion-f37cd7-1 into main
pull from: worker/612-r12-exhaustion-f37cd7-1
merge into: fleet:main
Conversation 1 Commits - Files Changed -
agent commented 2026-10-01 16:38:34 +02:00
Member
Copy Link
Copy Source

Part of fleetd #612 step 4 — one of four parallel units pinning call sites in FleetdAssembly.java that could be swapped for an inert variant with the full suite staying green (the #602/#606-shaped defect).

Scope: the exhaustion wirings (ticket ranks 1 and 2), four call sites in FleetdAssembly.java (measured on 26f1986):

  • line 164 forwardingExhaustionSink = Fleetd.forwardingExhaustionSink(exhaustionSinkRef)
  • lines 299-300 liveExhaustedPatterns / exhaustedPatterns
  • line 327 exhaustionSink = Fleetd.publishExhaustionSink(...)

New tests:

  • FleetdExhaustedPatternAssemblyTest — drives the real assembled CompletionResolver (via FleetdAssembly.assembleAndStart) through a pane scrape matching a configured exhaustedPattern, asserts the resolution classifies BACKEND_EXHAUSTED (rank 1 — the ticket's 'worst consequence in the whole sweep': a genuine usage-limit refusal handed back as real completed work) and that the real BackendQuarantine the same assembly built actually quarantines the credential (rank 2, the publishExhaustionSink half).
  • FleetdOpenCodeExhaustionForwardingAssemblyTest — pins forwardingExhaustionSink (rank 2, the OpenCode half, independent per the ticket) by reflectively reaching the real, assembled OpenCodeLauncher's exhaustionSink field (SessionManager.launcher -> CompositePeerLauncher.byProfile -> OpenCodeLauncher.exhaustionSink, since FleetdRuntime deliberately exposes no accessor down to adapter instances) and proving it forwards into the same production BackendQuarantine.

Both tests carry loud CONTROL assertions, each proven capable of failing on its own (flipped true/false locally, observed RED, reverted) before being trusted as the mutation-cycle signal.

Mutation-cycle proof, all four sites (grep-anchor -> line-anchored sed -> mvn -o compile -> full mvn -o test RED -> restore -> full mvn -o test GREEN at 1885/0):

  • line 164 -> ExhaustionSink.none(): 1885 run, 1 failure (FleetdOpenCodeExhaustionForwardingAssemblyTest)
  • line 299 -> new LiveExhaustedPatterns(() -> Map.of()): 1885 run, 1 failure (FleetdExhaustedPatternAssemblyTest)
  • line 300 -> ExhaustedPatternLookup.none(): 1885 run, 1 failure (FleetdExhaustedPatternAssemblyTest)
  • line 327 -> ExhaustionSink.none(): 1885 run, 2 failures (both tests — mutating publishExhaustionSink also breaks the OpenCode path, since forwardingExhaustionSink reads the same exhaustionSinkRef that publishExhaustionSink sets; this confirms the documented construction-order dependency rather than weakening either site's own pin)

Final full mvn -o test on this branch: 1885 tests, 0 failures (baseline on main: 1883; +2 new test methods).

No source-text assertions anywhere — every assertion reads behaviour off the real assembled objects FleetdRuntime/runtime.sessions()/runtime.mcp() expose, never a copy and never .java file contents.

Diff is scoped to two new test files only — FleetdAssembly.java itself is untouched (three other workers are editing it in parallel this wave).

Part of fleetd #612 step 4 — one of four parallel units pinning call sites in FleetdAssembly.java that could be swapped for an inert variant with the full suite staying green (the #602/#606-shaped defect). **Scope: the exhaustion wirings (ticket ranks 1 and 2), four call sites in FleetdAssembly.java (measured on 26f1986):** - line 164 `forwardingExhaustionSink = Fleetd.forwardingExhaustionSink(exhaustionSinkRef)` - lines 299-300 `liveExhaustedPatterns` / `exhaustedPatterns` - line 327 `exhaustionSink = Fleetd.publishExhaustionSink(...)` **New tests:** - `FleetdExhaustedPatternAssemblyTest` — drives the real assembled `CompletionResolver` (via `FleetdAssembly.assembleAndStart`) through a pane scrape matching a configured `exhaustedPattern`, asserts the resolution classifies `BACKEND_EXHAUSTED` (rank 1 — the ticket's 'worst consequence in the whole sweep': a genuine usage-limit refusal handed back as real completed work) and that the real `BackendQuarantine` the same assembly built actually quarantines the credential (rank 2, the `publishExhaustionSink` half). - `FleetdOpenCodeExhaustionForwardingAssemblyTest` — pins `forwardingExhaustionSink` (rank 2, the OpenCode half, independent per the ticket) by reflectively reaching the real, assembled `OpenCodeLauncher`'s `exhaustionSink` field (`SessionManager.launcher` -> `CompositePeerLauncher.byProfile` -> `OpenCodeLauncher.exhaustionSink`, since `FleetdRuntime` deliberately exposes no accessor down to adapter instances) and proving it forwards into the same production `BackendQuarantine`. Both tests carry loud CONTROL assertions, each proven capable of failing on its own (flipped true/false locally, observed RED, reverted) before being trusted as the mutation-cycle signal. **Mutation-cycle proof, all four sites** (grep-anchor -> line-anchored sed -> mvn -o compile -> full mvn -o test RED -> restore -> full mvn -o test GREEN at 1885/0): - line 164 -> ExhaustionSink.none(): 1885 run, 1 failure (FleetdOpenCodeExhaustionForwardingAssemblyTest) - line 299 -> new LiveExhaustedPatterns(() -> Map.of()): 1885 run, 1 failure (FleetdExhaustedPatternAssemblyTest) - line 300 -> ExhaustedPatternLookup.none(): 1885 run, 1 failure (FleetdExhaustedPatternAssemblyTest) - line 327 -> ExhaustionSink.none(): 1885 run, 2 failures (both tests — mutating publishExhaustionSink also breaks the OpenCode path, since forwardingExhaustionSink reads the same exhaustionSinkRef that publishExhaustionSink sets; this confirms the documented construction-order dependency rather than weakening either site's own pin) Final full mvn -o test on this branch: **1885 tests, 0 failures** (baseline on main: 1883; +2 new test methods). No source-text assertions anywhere — every assertion reads behaviour off the real assembled objects FleetdRuntime/runtime.sessions()/runtime.mcp() expose, never a copy and never .java file contents. Diff is scoped to two new test files only — FleetdAssembly.java itself is untouched (three other workers are editing it in parallel this wave).
agent added 1 commit 2026-10-01 16:38:34 +02:00
fleetd #612 step 4 (ranks 1&2): behavioural assembly tests for the exhaustion wirings
CI / shell-tests (pull_request) Failing after 6s
Details
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 3m5s
Details
2be287ea03 
Replaces nothing (no existing test covered these call sites through the real
assembly); adds two new FleetdAssembly-driven tests, matching Unit A's pattern
of inspecting FleetdRuntime's real, assembled objects rather than a copy.

- FleetdExhaustedPatternAssemblyTest pins the liveExhaustedPatterns/
  exhaustedPatterns call sites (rank 1 — "the worst consequence in the whole
  sweep": a genuine usage-limit refusal handed back as real completed work)
  together with publishExhaustionSink (rank 2, non-OpenCode half): drives a
  real CompletionResolver through a pane scrape matching a configured
  exhaustedPattern and asserts BACKEND_EXHAUSTED classification plus a real
  BackendQuarantine credential quarantine.

- FleetdOpenCodeExhaustionForwardingAssemblyTest pins forwardingExhaustionSink
  (rank 2, OpenCode half — independent of publishExhaustionSink per the
  ticket) by reflectively reaching the real, assembled OpenCodeLauncher's
  exhaustionSink field (SessionManager.launcher -> CompositePeerLauncher.
  byProfile -> OpenCodeLauncher.exhaustionSink) and proving it forwards into
  the same production BackendQuarantine.

All four call sites (FleetdAssembly.java:164,299,300,327) were each put
through grep-anchor -> line-anchored sed mutation -> mvn -o compile -> full
mvn -o test (named test RED) -> restore -> full mvn -o test (1885/0 GREEN).
Mutating line 327 alone also fails the OpenCode test, confirming the
documented construction-order dependency (forwardingExhaustionSink reads
exhaustionSinkRef, which publishExhaustionSink sets) without weakening either
site's independent pin.
ltms commented 2026-10-01 19:29:41 +02:00
Owner
Copy Link
Copy Source

Closing: this is already on main, and the forge did not notice.

Measured on 2026-10-01 at main = 141ae3b:

  • git rev-list --count origin/main..refs/pull/634/head → 0.
  • The tip 2be287e is an ancestor of origin/main.
  • The merge commit is 180c953 ("Merge PR #634: fleetd #612 ranks 1+2 — behavioural pins for the exhaustion wirings"), and 2be287e is a direct parent of it.

The merge was done in the local clone and pushed, so Gitea never marked the PR merged.

Closing: this is already on `main`, and the forge did not notice. Measured on 2026-10-01 at `main` = `141ae3b`: - `git rev-list --count origin/main..refs/pull/634/head` → **0**. - The tip `2be287e` is an ancestor of `origin/main`. - The merge commit is `180c953` ("Merge PR #634: fleetd #612 ranks 1+2 — behavioural pins for the exhaustion wirings"), and `2be287e` is a **direct parent** of it. The merge was done in the local clone and pushed, so Gitea never marked the PR merged.
ltms closed this pull request 2026-10-01 19:30:12 +02:00
Some checks are pending
CI / shell-tests (pull_request) Failing after 6s
Details
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 3m5s
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
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#634
Delete Branch "worker/612-r12-exhaustion-f37cd7-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?