-
Notifications
You must be signed in to change notification settings - Fork 394
fix(proxy): retry detached API key release #1545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Soju06
merged 4 commits into
Soju06:main
from
mastertyko:fix/retry-detached-api-key-release
Aug 6, 2026
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
86344cd
fix(proxy): retry detached API key release
mastertyko c77b1fe
fix(review): P1 - preserve inline stream release latency
mastertyko 11d9d4e
fix(review): P1 - bound detached release retry fan-out
mastertyko 7469430
chore(proxy): merge main into detached release retry
mastertyko File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 changes: 2 additions & 0 deletions
2
openspec/changes/retry-detached-api-key-release/.openspec.yaml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,2 @@ | ||
| schema: spec-driven | ||
| created: 2026-07-30 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,66 @@ | ||
| ## Context | ||
|
|
||
| Stream reservation settlement is detached from the response path. A failed | ||
| settlement schedules one release task in the existing tracked background-task | ||
| set, but that release currently catches its own exception and returns normally. | ||
| The done callback consequently removes the task, so the persistence drain can | ||
| report success while the reservation remains active. | ||
|
|
||
| Reservation release is already transactional and idempotent: once another | ||
| settler has changed the reservation from `reserved`, a later release is a | ||
| no-op. The existing stale sweep remains a last-resort repair, but its six-hour | ||
| age threshold is too slow for a known live cleanup chain. | ||
|
|
||
| ## Goals / Non-Goals | ||
|
|
||
| **Goals:** | ||
|
|
||
| - Keep transiently failing fallback release work visible to the existing task | ||
| drain. | ||
| - Retry until the idempotent release succeeds, with bounded retry pressure. | ||
| - Preserve detached response latency, settlement-before-health ordering, and | ||
| exactly-once accounting. | ||
|
|
||
| **Non-Goals:** | ||
|
|
||
| - Changing reservation amounts, quota admission, or stale-sweep timing. | ||
| - Adding a durable job queue, setting, migration, or new public API. | ||
| - Refactoring request-log persistence or unrelated cleanup ownership. | ||
|
|
||
| ## Decisions | ||
|
|
||
| 1. **Retry inside the already tracked release task.** The release coroutine | ||
| stays pending between attempts, so the current task registry and recursive | ||
| drain remain the single source of cleanup ownership. Creating a second | ||
| registry or a durable retry row would duplicate state for a narrow failure. | ||
|
|
||
| 2. **Use capped exponential delay plus a shared retry gate for every persistence | ||
| exception.** The outer retry covers transient PostgreSQL/session failures | ||
| that the API-key service's SQLite-lock-specific retry does not classify. A | ||
| fixed delay cap prevents each task from retrying rapidly, while a per-service | ||
| concurrency gate prevents many failed streams from opening repository | ||
| sessions simultaneously. Waiting tasks stay tracked without holding a | ||
| database connection. | ||
|
|
||
| 3. **Rely on reservation transition idempotency.** A retry cannot double | ||
| decrement quota: release only claims a reservation still in `reserved` | ||
| state, and a concurrent finalizer or release makes subsequent attempts | ||
| no-ops. | ||
|
|
||
| 4. **Let the existing drain deadline bound shutdown waiting.** A recovered | ||
| release completes normally. A release still retrying at the deadline remains | ||
| pending, so `drain_persistence_tasks` returns `False` instead of claiming | ||
| durability. No separate retry-count terminal state is introduced. | ||
|
|
||
| ## Risks / Trade-offs | ||
|
|
||
| - **A permanent persistence error leaves a task alive during normal runtime.** | ||
| → Retries use capped backoff; the task accurately represents unfinished | ||
| cleanup, and stale recovery remains the final repair path. | ||
| - **Many simultaneous failures could retry together after an outage.** | ||
| → A shared four-attempt gate bounds aggregate repository pressure in each | ||
| service instance; exponential delay also bounds each task's retry frequency, | ||
| and the change adds no inline request-path work. | ||
| - **Cancellation can stop a retry after shutdown has already timed out.** | ||
| → The drain first reports incomplete, so process termination cannot be | ||
| mistaken for successful settlement. |
34 changes: 34 additions & 0 deletions
34
openspec/changes/retry-detached-api-key-release/proposal.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| ## Why | ||
|
|
||
| A detached stream settlement can fail, enqueue its reservation-release fallback, | ||
| and then lose the reservation when that fallback also hits a transient | ||
| persistence failure. The task drain reports success even though the reservation | ||
| still consumes quota until stale recovery runs hours later. | ||
|
|
||
| ## What Changes | ||
|
|
||
| - Keep a failed detached reservation release tracked and retry it after | ||
| transient persistence failures, with a shared concurrency bound on repository | ||
| attempts. | ||
| - Make the persistence drain report completion only after the tracked | ||
| settlement/release chain has actually terminated. | ||
| - Add deterministic regression coverage for a finalize failure followed by one | ||
| failed release attempt, while preserving successful settlement, cancellation, | ||
| and SQLite-lock behavior. | ||
|
|
||
| ## Capabilities | ||
|
|
||
| ### New Capabilities | ||
|
|
||
| None. | ||
|
|
||
| ### Modified Capabilities | ||
|
|
||
| - `api-keys`: Clarify that a detached settlement fallback which itself fails | ||
| transiently remains tracked and retries before persistence drain can succeed. | ||
|
|
||
| ## Impact | ||
|
|
||
| The change is limited to detached API-key reservation cleanup in the proxy | ||
| service, its focused persistence tests, and the existing API-key settlement | ||
| contract. It adds no API, setting, dependency, migration, or dashboard change. |
45 changes: 45 additions & 0 deletions
45
openspec/changes/retry-detached-api-key-release/specs/api-keys/spec.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,45 @@ | ||
| ## MODIFIED Requirements | ||
|
|
||
| ### Requirement: Stream reservation settlement is detached from the response path | ||
|
|
||
| Settling a stream API-key reservation MUST NOT block the response/stream close, with one deliberate exception: when a keyed websocket stream terminates with an account-health error, the finalizer MUST wait for the settlement to commit before the load-balancer health write (the settlement-ordering invariant), so that error path intentionally blocks on settlement. In all other cases the settlement MUST run as a tracked background task; when it fails or is cancelled, the reservation MUST still be released by the tracking fallback, and the request's finalization path MUST NOT double-release a transferred settlement. If the tracking fallback itself encounters a persistence failure, it MUST remain tracked and retry the idempotent release; no more than four retry-enabled detached fallback repository attempts may run concurrently per proxy service instance, waiting fallbacks MUST NOT open repository sessions until admitted, and persistence drain MUST NOT report completion while any retry remains unfinished. Reservations MUST continue to count toward key limits until finalized or released, so deferred settlement can never admit usage a synchronous settlement would have rejected. | ||
|
|
||
| #### Scenario: Response close precedes settlement completion | ||
|
|
||
| - **GIVEN** a keyed stream whose settlement transaction is still running | ||
| - **WHEN** the stream closes | ||
| - **THEN** the close does not wait for the settlement | ||
| - **AND** the settlement finalizes the reservation exactly once in the background | ||
|
|
||
| #### Scenario: Failed detached settlement still releases the reservation | ||
|
|
||
| - **GIVEN** a detached settlement whose finalize raises | ||
| - **WHEN** the settlement task completes | ||
| - **THEN** the tracking fallback releases the reservation | ||
|
|
||
| #### Scenario: Failed fallback release remains tracked | ||
|
|
||
| - **GIVEN** a detached settlement whose finalize raises | ||
| - **AND** the first tracking-fallback release attempt also raises | ||
| - **WHEN** persistence recovers before the drain deadline | ||
| - **THEN** the tracked fallback retries and releases the reservation exactly once | ||
| - **AND** persistence drain does not report completion before that release | ||
|
|
||
| #### Scenario: Concurrent fallback release retries are bounded to four | ||
|
|
||
| - **GIVEN** five failed detached settlements in one proxy service instance | ||
| - **WHEN** their tracking fallbacks attempt repository persistence concurrently | ||
| - **THEN** no more than four release attempts open repository sessions | ||
| - **AND** the waiting fallbacks remain tracked until they can retry | ||
|
|
||
| #### Scenario: Websocket health-error settlement precedes the health write | ||
|
|
||
| - **GIVEN** a keyed websocket stream that terminates with an account-health error | ||
| - **WHEN** the finalizer settles the reservation | ||
| - **THEN** it waits for the settlement to commit before recording the account-health error | ||
|
|
||
| #### Scenario: Shutdown drains pending settlements | ||
|
|
||
| - **WHEN** the service shuts down gracefully with settlements in flight | ||
| - **THEN** shutdown waits for them up to the configured drain timeout | ||
| - **AND** reports an incomplete drain if a tracked settlement or release remains unfinished at that timeout |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| ## 1. Regression | ||
|
|
||
| - [x] 1.1 Add a real-repository regression that injects one finalize failure and one fallback-release failure. | ||
| - [x] 1.2 Confirm the regression fails deterministically twice on baseline `3fe0d6f286019a0505783d803db9a1d8cdf6b307`. | ||
|
|
||
| ## 2. Implementation | ||
|
|
||
| - [x] 2.1 Keep the fallback release tracked while retrying persistence failures with capped backoff. | ||
| - [x] 2.2 Preserve idempotent settlement, cancellation ownership, and truthful persistence-drain behavior. | ||
| - [x] 2.3 Bound concurrent fallback repository attempts to four with one shared per-service gate. | ||
|
|
||
| ## 3. Verification | ||
|
|
||
| - [x] 3.1 Run the focused detached-settlement and API-key reservation tests. | ||
| - [x] 3.2 Run changed-file Ruff, format, type, proxy-architecture, and strict OpenSpec checks. | ||
| - [x] 3.3 Inspect the final diff and worktree status for scope and unrelated changes. | ||
| - [x] 3.4 Add deterministic fan-out coverage for the shared retry concurrency bound. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.