CB-583: capacity view reports free:0 for a quarantined profile #62

Closed
agent wants to merge 0 commits from worker/cb583-b82d11-2 into main
Member

Finishes acceptance criterion 7 of issue #50, which CB-578 stage B did not meet: bridge_list's capacity view was a separate CapacitySource that knew nothing about BackendQuarantine, so a quarantined profile still showed free slots.

Changes:

  • capacityView() now takes the same QuarantineSource bridge_profiles reads (BridgeMcp.java, no duplicate quarantine lookup).
  • When a profile's credential is quarantined, its capacity row forces free:0 (whatever maxLoad/live say) and adds credentialId + quarantinedForSeconds, matching bridge_profiles's field names.
  • Both new keys are added only when the profile is actually quarantined — an ordinary fleet's capacity rows are byte-identical to before.
  • listFleet's full overload gained a required QuarantineSource parameter (no defaulted/convenience overload); the 4-arg test-only overload passes QuarantineSource.none() to preserve its existing behavior.
  • Updated bridge_list's tool description to document the new fields.

Tests added in BridgeMcpTest: quarantined profile -> free:0 regardless of maxLoad/live; every profile sharing the credential -> free:0; capacity row carries credentialId/quarantinedForSeconds; ordinary fleet has no new keys; quarantine expiry on the injected clock returns free to normal; bridge_list and bridge_profiles agree on what is quarantined.

Build: mvn -f bridged/pom.xml clean install, unpiped — BUILD SUCCESS, Tests run: 744, Failures: 0, Errors: 0.

Scope note: stayed out of session/SessionManager.java, session/GitWorktrees.java and msg/MessageService.java (CB-578 stage C, in flight on another branch). Only touched Bridged.java-adjacent wiring inside BridgeMcp.java itself; Bridged.java was not touched.

Finishes acceptance criterion 7 of issue #50, which CB-578 stage B did not meet: bridge_list's capacity view was a separate CapacitySource that knew nothing about BackendQuarantine, so a quarantined profile still showed free slots. Changes: - capacityView() now takes the same QuarantineSource bridge_profiles reads (BridgeMcp.java, no duplicate quarantine lookup). - When a profile's credential is quarantined, its capacity row forces free:0 (whatever maxLoad/live say) and adds credentialId + quarantinedForSeconds, matching bridge_profiles's field names. - Both new keys are added only when the profile is actually quarantined — an ordinary fleet's capacity rows are byte-identical to before. - listFleet's full overload gained a required QuarantineSource parameter (no defaulted/convenience overload); the 4-arg test-only overload passes QuarantineSource.none() to preserve its existing behavior. - Updated bridge_list's tool description to document the new fields. Tests added in BridgeMcpTest: quarantined profile -> free:0 regardless of maxLoad/live; every profile sharing the credential -> free:0; capacity row carries credentialId/quarantinedForSeconds; ordinary fleet has no new keys; quarantine expiry on the injected clock returns free to normal; bridge_list and bridge_profiles agree on what is quarantined. Build: mvn -f bridged/pom.xml clean install, unpiped — BUILD SUCCESS, Tests run: 744, Failures: 0, Errors: 0. Scope note: stayed out of session/SessionManager.java, session/GitWorktrees.java and msg/MessageService.java (CB-578 stage C, in flight on another branch). Only touched Bridged.java-adjacent wiring inside BridgeMcp.java itself; Bridged.java was not touched.
agent added 1 commit 2026-08-15 12:51:58 +02:00
CB-583: make bridge_list's capacity view quarantine-aware
CI / contract (pull_request) Successful in 44s
CI / build (pull_request) Successful in 1m32s
165b62ee20
A quarantined profile's capacity row now forces free:0 and names the
quarantine (credentialId, quarantinedForSeconds), reusing the same
QuarantineSource bridge_profiles already reads instead of a second
lookup. An ordinary fleet's capacity rows are unchanged (no new keys).
ltms closed this pull request 2026-08-15 13:09:35 +02:00
Some checks are pending
CI / contract (pull_request) Successful in 44s
CI / build (pull_request) Successful in 1m32s

Pull request closed

Sign in to join this conversation.