Repository navigation
fix(threads): replay the thread's tail after a provider switch or dropped session (#1493 A, #237) - #1494
Conversation
setProvider dropped the old CLI's session without setting replayContext, so the next run (and every quota failover, which routes through it) started with no history. Any session drop in setProvider now sets replayContext, reusing the #254 rewind digest of the thread's own retained tail. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4dff0dd03a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (patch.sessionId === null) { | ||
| // The new CLI (or re-pinned model) starts with no memory of this thread. | ||
| // Replay its own retained tail on the next send, same as a rewind (#254), | ||
| // or a switch mid-task (and quota failover) restarts blind (#1493). | ||
| patch.replayContext = true; |
There was a problem hiding this comment.
On automatic quota failover, the first attempt has already appended the current user message before setProvider enables replayContext; the resumed startRun then builds the replay tail from that transcript and separately appends the same prompt to the CLI input. Consequently every session-bearing failover sends the request twice (user: keep going inside the hand-off block and keep going again afterward), which can cause duplicated actions and displaces older messages from the capped replay tail. The replay path should omit the in-flight user message when fromQuotaFailover is set.
Useful? React with 👍 / 👎.
Item A of #1493, also #237.
Bug:
setProvider(electron/services-threads.js) nulledsessionIdon a provider or model-pin change but set neitherreplayContextnorhandoffFrom. SobuildHandoffPrefixreturned "" and the next run started with no history. Automatic quota failover (runner-quota-wait.js) goes through the same path, so a thread that failed over mid-task also restarted blind. A worktree move that drops the session (Store.updateThreadworktreePath rule) had the same hole.Fix: whenever a session is dropped on a thread that had one, set
replayContext: true. The next send then digests the thread's own retained tail, the same mechanism a rewind (#254) uses. The runner clears the flag after use.Verified independently
provider-switch-context.test.jsfails on main (4 of 5): manual switch, quota failover, model-pin switch, and worktree move. The test that a brand-new thread gets no prefix passes on both.🤖 Generated with Claude Code