You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Snoozing a thread whose queue is held after Stop fails with:
Thread 4c2e9e32-25fa-4625-a61e-f60d358959f0 has a queued run and cannot be snoozed.
The menu offers Snooze, the server rejects it, and nothing in the thread explains why. I'd like a maintainer call on the intended behavior before sending a fix.
What happened
Orchestrator V2, Claude provider, thread with PR watch enabled. Runs from the live statev2.sqlite (read-only):
run
source
status
notes
46
PR watch
cancelled 00:14:47
I pressed Stop
47
PR watch, arrived 00:13:36 while 46 ran
queued, queueHeld: true, queuePosition: 1
never started
48
PR watch, arrived 00:27:56
completed 00:28:21
started directly, ahead of 47
Snooze was attempted after run 48 finished. Run 47 is still held.
Why
Stop holds every queued run (Orchestrator.ts#L8081-L8095). That part is intended. The queue waits for Resume.
A new message is queued only when a run is active (#L4695-L4699). A held queue doesn't count, so run 48 started immediately and jumped ahead of 47.
startNextQueuedRun returns early while any queued run is held (#L1215-L1223), so 47 stays held until someone presses Resume.
The snooze decider rejects any queued run, held or not (#L2650-L2656). A held run won't start on its own, so the "thread is about to become active" reasoning doesn't apply to it.
The client twin canSnooze (threadSettled.ts#L137-L153) checks only runtime status and latestRun/latestTurn via hasQueuedTurnStart. latestRun is the completed run 48, so the client allows Snooze and the server refuses. The comment in useThreadActions.ts calls canSnooze the "client-side twin of the server invariants", and here the two disagree.
Workaround: open the thread, then Resume or cancel the held message.
Options
A. Let snooze ignore held queued runs. One condition in the decider plus a test. Resume on a snoozed thread starts a run, and run activity already wakes snoozed threads. This changes product behavior.
B. Keep the server rule and make the client match.canSnooze has to see any queued run, not only the latest one. The thread shell carries no queue data, so web and mobile both need it plumbed through. No behavior change, more code.
Separate question: should a new message start while older queued runs are held (step 2)? If that's intended, a held message can sit unnoticed behind newer work, which is how this thread got here.
I lean towards B, possibly with A, depending on the answer to the held-queue question. Not a duplicate of #14819 (snooze a running thread) or #15586 (MCP error text replacement).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Snoozing a thread whose queue is held after Stop fails with:
The menu offers Snooze, the server rejects it, and nothing in the thread explains why. I'd like a maintainer call on the intended behavior before sending a fix.
What happened
Orchestrator V2, Claude provider, thread with PR watch enabled. Runs from the live
statev2.sqlite(read-only):cancelled00:14:47queued,queueHeld: true,queuePosition: 1completed00:28:21Snooze was attempted after run 48 finished. Run 47 is still held.
Why
Orchestrator.ts#L8081-L8095). That part is intended. The queue waits for Resume.#L4695-L4699). A held queue doesn't count, so run 48 started immediately and jumped ahead of 47.startNextQueuedRunreturns early while any queued run is held (#L1215-L1223), so 47 stays held until someone presses Resume.queuedrun, held or not (#L2650-L2656). A held run won't start on its own, so the "thread is about to become active" reasoning doesn't apply to it.canSnooze(threadSettled.ts#L137-L153) checks onlyruntimestatus andlatestRun/latestTurnviahasQueuedTurnStart.latestRunis the completed run 48, so the client allows Snooze and the server refuses. The comment inuseThreadActions.tscallscanSnoozethe "client-side twin of the server invariants", and here the two disagree.Workaround: open the thread, then Resume or cancel the held message.
Options
canSnoozehas to see any queued run, not only the latest one. The thread shell carries no queue data, so web and mobile both need it plumbed through. No behavior change, more code.Separate question: should a new message start while older queued runs are held (step 2)? If that's intended, a held message can sit unnoticed behind newer work, which is how this thread got here.
I lean towards B, possibly with A, depending on the answer to the held-queue question. Not a duplicate of #14819 (snooze a running thread) or #15586 (MCP error text replacement).
All reactions