Repository navigation
Conversation
The test fails on main. The completion run starts on the selection copied when it was queued, and the start writes that copy back to the thread.
A delegated-task completion is queued with no selection of its own, so its run stores a copy of the thread's selection. Starting on that copy reverted a model change made while the notice waited. Queued delegated completions now follow the thread's current selection and conversation, as queued PR-watch updates do since pingdotgg#21314.
6febf86 to
282206f
Compare
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Title check |  |
The title clearly and concisely identifies the main fix: queued delegated completions preserve a newer model choice. |
| Description check | |
The description covers the problem, change, scope and approval rationale, focused verification, test results, known failures from boundary checking, and the unperformed live-provider check. |
| Linked Issues check | |
The PR satisfies the active coding requirements in [#22577]. followsCurrentConversation now includes delegated-completion messages, so a queued completion uses the thread's current selection and con… |
| Out of Scope Changes check | |
The reported changes are limited to the delegated-completion queue-selection condition, its related comment removal, and a focused regression test. These changes directly implement [#22577]. The evide… |
Full details: Linked Issues check
-
Explanation
The PR satisfies the active coding requirements in [
#22577].followsCurrentConversationnow includes delegated-completion messages, so a queued completion uses the thread's current selection and conversation instead of its enqueue-time copy. The addedruntimeLayer.test.tsregression test covers model changes within the same provider instance and across provider instances. The described behavior preserves queued user-message selections from contextual [#19376] and preserves immediate late-steer behavior.
Full details: Out of Scope Changes check
-
Explanation
The reported changes are limited to the delegated-completion queue-selection condition, its related comment removal, and a focused regression test. These changes directly implement [
#22577]. The evidence shows no unrelated contract, client, provider-adapter, or user-message changes.
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
Problem
A delegated-task completion notice that waits in the queue reverts the thread's model when it starts. If the model changes while the notice waits, with the picker or
t3_thread_configure, the notice's turn and the turns after it run on the old model. The expected behavior is that the notice starts on the thread's current model and leaves it unchanged.Change
ProviderContinuationServicequeues the notice with nomodelSelection, somessage.dispatchstores a copy of the thread's selection on the run. At start,queuedRunModelSelectionreturned that copy, and the start wrote it back to the thread. A queued delegated completion now starts on the thread's current selection and conversation. #21314 gave queued PR-watch updates the same rule. The change adds one condition tofollowsCurrentConversationand drops a comment that named only monitor updates.Queued messages that a user sends carry the composer's selection and keep it, as #19376 intends.
The late-steer follow-up in
EffectWorkerpasses its run's selection when it dispatches. If that follow-up waits in the queue, it now also starts on the thread's current selection. If it starts at once, it uses its run's selection as before. The two selections differ only when the model changed while the steered run was active.Scope and approval
Fixes #22577, which has the diagnosis and the reproduction steps and is awaiting triage. The change also qualifies as a small, focused fix for an obvious bug. A notice that the app created reverted a model that a user or an agent had chosen. The fix applies #21314's rule to one more kind of app-owned queued update. It changes no contract, client, provider adapter or user-message behavior.
Verification
thread.model-selection-updatedevent with no command. Each event restored the enqueue-time selection over at3_thread_configurechange from about a minute earlier. A queued delegated-task completion reverts a model change made while it waited #22577 has the event log.runtimeLayer.test.ts, "starts a queued delegated completion on a selection set while it waited", queues a notice shaped likeProviderContinuationService's delivery. It then changes the thread's model, completes the active run and starts the queue. It has two cases, a model change on the same provider instance and a switch to another instance.main(4f651cb), both cases fail. The run starts ongpt-5.4instead ofgpt-5.5, andthread.modelSelectionreverts togpt-5.4.vp test runpasses 177 of 177 tests in the 8 related files:runtimeLayer,DelegatedCompletionDelivery,SteeringCompletion.integration,ProviderContinuationService,QueuedRunOrder,testkit/ProviderSwitch.integration,ClaudeAutomaticDelivery.integrationandEffectWorker.vp fmt --checkandvp lintpass on the changed files, apart from one existing warning on an untouched line.delegate_taskchild.Created with Claude Opus 5.5 in Claude Code (T3 Code).