Snooze is offered but rejected when a thread's queue is held after Stop

[Guria]

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

1. Stop holds every queued run (Orchestrator.ts#L8081-L8095). That part is intended. The queue waits for Resume.
2. 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.
3. startNextQueuedRun returns early while any queued run is held (#L1215-L1223), so 47 stays held until someone presses Resume.
4. 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.
5. 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).

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Resolved by #19099 — snoozed threads now allow queued automatic wakes (notifications / delegated completions), and buffered provider wakes are cancelled on Stop/recovery when their output was discarded.