[Bug]: Snooze stays disabled for 2 minutes after a steered follow-up message#23778
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Impact
Minor bug or occasional failure. Snooze is unavailable for up to 2 minutes and then works on its own. Reporting it because the cause is a clear logic gap, not because it blocks anything.
Steps to reproduce
- Start a turn in a thread and let it keep running.
- While it runs, send a follow-up message that gets steered into the running turn (in this case "Hold on, pause for a minute.").
- Let the running turn finish.
- Open the thread's context menu in the sidebar.
Expected behavior
Snooze is enabled once the steered message has been taken into the running turn and nothing is pending.
Actual behavior
Snooze stays disabled until 2 minutes after the steered message (QUEUED_TURN_START_GRACE_MS), then becomes enabled without any other change.
Cause, from persisted state (orchestration_v2_projection_runs / orchestration_v2_projection_messages), times UTC:
| Record | requestedAt | startedAt | completedAt / createdAt |
|---|---|---|---|
| run 352 (running turn) | 18:45:43.625 | 18:45:44.736 | 18:47:01.270 |
run 353 (userMessageId = the steered message, status cancelled) | 18:46:44.211 | null | 18:46:51.579 |
steered user message (runId = run 352) | created 18:46:51.656 |
Sending the message queued run 353. When the message was steered into run 352, run 353 was cancelled without starting, and the message's createdAt was stamped 77 ms after run 353's completedAt.
hasQueuedTurnStart in packages/client-runtime/src/state/threadSettled.ts uses shell.latestRun ?? shell.latestTurn, which is run 353. Every timestamp on run 353 is earlier than latestUserMessageAt, so it returns true and canSnooze returns false until the grace window expires (18:48:51.656). The snooze then went through at 18:49:20.560 (snoozedAt).
The same check feeds the settle/queued state, so those may be affected too in this window.
Possible fixes: skip runs that were cancelled without starting when choosing the run to compare against, or treat a user message whose runId points at a run that has started as already adopted.
Version or commit
T3 Code Nightly 0.1.2-nightly.20261021.3486 (installed desktop build). hasQueuedTurnStart and canSnooze are unchanged on main at 4eae8ae011.
Environment
Linux desktop AppImage, Claude Code provider (claudeAgent), model claude-opus-5-5.
Workaround
Wait 2 minutes after the steered message.