Repository navigation
Retire ACP attachments through canonical warm-worker policy - #2062
Merged
Brian Krabach (bkrabach) merged 4 commits intoNov 14, 2026
Merged
Conversation
Brian Krabach (bkrabach)
deleted the
feat/acp-conditional-retirement-20261114
branch
November 14, 2026 17:31
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Behavior
External ACP attachments currently keep their native workers outside automatic retention. This adds an optional conditional retirement operation and a policy-driven request signal, allowing a cooperating client to release an attachment only after its exact native owner confirms quiescence.
The existing warm-worker policy remains authoritative: 32 warm workers and 12 idle hours by default, plus pending generation updates. Ordinary turn completion does not request cleanup. Attached candidates are notified by the existing retention sweep, and current policy is checked again under admission before the native acknowledgement. Background work and its connection-bound tools remain intact after refusal, uncertainty or a lost result. Confirmed cleanup preserves durable session identity; the next message pays worker startup and resumes without replay. Connections without mounted tools also receive a notification after canonical native retirement completes, including a late acknowledgement. Notification failure cannot undo that result. No additional timer, configuration or concurrency cap is introduced.
The private optional extension negotiates
_amplifier/retirementRequested; olderretirementAvailablemetadata does not opt into automatic cleanup. A successful receipt covers only the exact single-session attachment and is repeatable after a lost response. The consumer fence and automatic exact-ID reconnect remain a separate successor.Validation
Owned-DTU maintained checks: 84 distinct cases pass across an initial 78 passes / 6 failures and a corrected six-case run. The failures were one unchanged local test stub that omitted the existing keyword-only admission guard; the correction forwards it and preserves the assertions. Coverage includes canonical count/age/update retention, stale-demand refusal, mounted background context access after refusal, native acknowledgement, cancellation/timeout/replacement, and actual SDK authorization and creation races. All 3,875 executed source hashes match this exact candidate.
Earlier producer qualification remains separately bound to 4f4a394: 58 distinct cases across 59 executions. The policy successor dcf03f2 is independently source/result reviewed. A further 11 focused completion checks passed (five new cases and six relevant controls), covering empty-tool ordinary/late acknowledgement, refusal/uncertainty, admission-lock release and failed notification delivery. Current producer head is eb4cb7a; its last change is documentation only after the tested aef4436 completion successor. No model, live-service change or release adoption. Actual published Instance forwarding/reconnect qualification is retained separately with the consumer.