镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

fix(server): queued PR updates resume on a compatible provider again - #370

Merged
shuv1337 merged 1 commit into
mainfrom
fix/provider-switch-queued-pr-update
Nov 3, 2026
Merged

shuv1337 merged 1 commit into
mainfrom
fix/provider-switch-queued-pr-update

Conversation

@shuv1337

@shuv1337 shuv1337 commented Nov 3, 2026

Copy link
Copy Markdown
Owner

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) and 2de863cd14 (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 !instanceChanged to canResumeAcrossInstances in startQueuedRun. 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. But instanceChanged is 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 what canResumeAcrossInstances exists for. With the guard, the update skipped the resume, tried a full-summary handoff the target cannot take, and failed with context_handoff_unsupported before 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 resolveSpentInstance actually moved the run off its requested instance. Otherwise the code behaves like upstream again (upstream has no such guard).

Verification

  • ProviderSwitch.integration.test.ts 5 runs in a row: 42/42 passing each time.
  • The UsageLimitFailover cases starts 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.
  • The full UsageLimitFailover.integration.test.ts fails the same 10 tests on main and 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 typecheck passes, and so does vp run check:changed.

Claude Opus 5.5 via Cursor in T3 Code.

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>
@shuv1337
shuv1337 merged commit e6b4f3e into main Nov 3, 2026
11 of 21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Flaky: ProviderSwitch.integration queue.resume test

1 participant