Repository navigation
Conversation
…w has room Handoff delivery budgeted against the remaining window minus a reserve of max(16k, window/4). Once a thread used more than the window minus that reserve, the budget was 0, and any pending handoff that was not skippable failed the turn with ContextHandoffBudgetError, even when the window still had room. Failed turns left their handoffs pending and added more, so every later prompt failed too. A same-native-thread handoff now falls back to a pointer-only note sized against the real remaining window, records the dropped history as omitted, and still throws when even the pointer cannot fit. A missed-run retry note that has no room is skipped, since the turns stay readable through the thread. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
jhomra21
force-pushed
the
fix/handoff-delivery-degrades-instead-of-failing
branch
from
October 18, 2026 14:47
38535e3 to
917dcd1
Compare
Thread transfer impact
This comment will update automatically after the next completed run. |
Use the remaining native context window for a compact recovery pointer before replacing a thread whose reserved handoff budget is exhausted. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
jhomra21
marked this pull request as draft
October 30, 2026 02:32
…off-delivery-degrades-instead-of-failing
…d-of-failing Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
This branch has not been deployed
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.
Problem
T3 reserves part of the context window for later work when it delivers a context handoff. In a long thread, that reserve can be used up while the native thread still has room for the prompt and a short recovery pointer. Delivery then fails. Upstream can now start a fresh native thread instead, but that drops the provider's own context, and it still fails when pending background work prevents the replacement.
Change
For the same native thread only, when the history doesn't fit the reserved budget,
deliverContextHandoffsnow tries a pointer-only handoff: no history messages, sized against the real remaining window thathandoffRemainingWindowmeasures. Omitted history item IDs go into the delivery metadata, as before. If the pointer doesn't fit either, delivery fails or starts a fresh thread exactly as it does today. Normal history delivery keeps the existing reserve.Scope and approval
This overlaps open PR pingdotgg#19414, which fixes the triaged pingdotgg#23275 and touches the same files. pingdotgg#19414 defers the whole handoff and sends the prompt unchanged, while this PR sends a pointer that fits the window. Related reports: pingdotgg#22636 (a Factory Droid switch-back blocked by the reserve) and pingdotgg#23142 (byte-based estimates and ACP window fallback, a different cause).
Verification
ContextHandoffBudget.test.tsfails on upstream mainb42adff3d7withexpected 'Failure' to equal 'Success'and passes with the fix. The file passes all 17 tests.ProviderTurnStartService.test.ts: 4 tests fail. The same 4 fail on clean upstream on this Windows machine: worktree recovery fails withENOENT, a recreation-interrupt case returnsSuccessinstead ofFailure, and two startup-coordination cases fail their assertions.vp env exec --node 26.12.1 -- vp run check:changed: format, lint, knip, GraphQL and typecheck passed. Its only test failures were the 4 above.Built with Claude Opus 5.5 through Factory Droid in T3 Code. Upstream preparation by GPT-6.1 Terra, orchestrated by Claude Opus 5.5, through Factory Droid in T3 Code.