Repository navigation
fix(server): queued PR updates resume on a compatible provider again - #370
Merged
Merged
Conversation
A queued monitor update that follows the user to a compatible instance again resumes the native conversation instead of failing on a handoff. Only work the spent-instance resolver moves off a quota-spent pool account starts a fresh pooled thread. Fixes #360. Co-authored-by: Cursor <cursoragent@cursor.com>
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.
Fixes #360.
The ProviderSwitch test
delivers a queued PR update on the current provider through queue.resume (compatible Codex)was not flaky. It fails every time, locally and in all four recent ci-full runs. The code is wrong and the test's expectation is right, so the test is unchanged.Root cause
Bisected between
dac32e60f8(passes) and2de863cd14(fails). The first bad commit is 21c9f74 (fix(server): preserve fresh pool failover and retry pending probes, merged in #348). #353 and #354 are not the cause; the test already failed before them.That commit added
!instanceChangedtocanResumeAcrossInstancesinstartQueuedRun. The aim was that a queued message the spent-instance resolver moves off a quota-spent pool account starts a fresh pooled thread with a handoff, and does not resume the spent account's chat. ButinstanceChangedis also true in upstream's pingdotgg#21314 case. There, a queued monitor update follows the user's own switch to a compatible instance that shares the continuation key. That path is whatcanResumeAcrossInstancesexists for. With the guard, the update skipped the resume, tried a full-summary handoff the target cannot take, and failed withcontext_handoff_unsupportedbefore any turn ran. That left one captured turn instead of two.Fix
Narrow the guard to what #348 meant: skip the cross-instance resume only when
resolveSpentInstanceactually moved the run off its requested instance. Otherwise the code behaves like upstream again (upstream has no such guard).Verification
ProviderSwitch.integration.test.ts5 runs in a row: 42/42 passing each time.UsageLimitFailovercasesstarts a queued run on a fresh pooled thread (resume compatible: false|true)still pass. With no guard at all, the compatible case fails, so the narrowed guard still covers it.UsageLimitFailover.integration.test.tsfails the same 10 tests onmainand on this branch. That file is not in CI yet, and test: restore UsageLimitFailover coverage and run it in CI #356 is restoring it.vp run --filter t3 --filter @t3tools/contracts --filter @t3tools/shared --filter @t3tools/web typecheckpasses, and so doesvp run check:changed.Claude Opus 5.5 via Cursor in T3 Code.