run-prompt: cold first tab ends submit_unconfirmed though the prompt was delivered (1.0.190)

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity

Closed general

John Lauer · 1mo ago ·closed by John Lauer

On 1.0.187+, a send that genuinely worked can end as submit_unconfirmed when it is the FIRST, cold AI tab on a slow machine. The prompt lands and the AI runs, but the job's terminal state says delivery was not confirmed, so every dock dashboard shows the user a hedge on a successful send.

Measured

Two clicks, kicad-bridge dashboard, ah 1.0.190 on winvm, driven through the shared newbie-panel.js 2.22.0 send path.

Click 1, cold (no Claude tab open):

moment	t
POST /ai-threads/run-prompt answered, job `f321e40b`	4.8 s
tab seen	1.5 s
submitted (send clicked)	7.0 s
sid identified (`277d91bf`)	28.6 s
terminal state `submit_unconfirmed`	~37 s

Reported reason: "the tab has its session, but no UserPromptSubmit hook arrived within 30s of the send click."

Click 2, warm (a Claude tab already open): submitted 4.9 s, sid d512fd40 identified 21.6 s, terminal state working. Same dashboard, same box, minutes apart.

The only material difference is cold vs warm. The 30 s hook window is measured from the 7.0 s submit click, so it expires at ~37 s, and the cold tab identified its session at 28.6 s with the hook arriving after the deadline.

Why this is worth fixing rather than documenting

The window is not tight everywhere, which is what makes it a trap. On AdomLapper, nb-bridge measured identified_ms of 1447 and 2517 on the same ah version. winvm's cold first tab is roughly ten times slower, so the same code is comfortably inside the window on one machine and outside it on another.

The user-visible consequence is the wrong way round. submit_unconfirmed is a terminal FAILURE state, so the shared panel resolves it as opened, not delivered, and the user is told "Sent, but delivery was not confirmed" for a prompt that actually arrived and is being answered. A user who believes that hedge and clicks again double-sends.

This may be a meaningful part of why Send to AI is currently perceived as unreliable: not sends that fail, but successful sends reported as unconfirmed on cold tabs.

Suggested direction

Measure the window from when the tab is IDENTIFIED rather than from the submit click, or extend it for the first cold tab of a session, or let a later hook arrival upgrade an already-terminal submit_unconfirmed to working. Any of the three removes the false negative without weakening the genuine submit_failed case (prompt in the tab, send never clicked), which is a different and still-useful state.

Provenance

Found by the kicad-bridge thread during the fleet rollout of the 1.0.187+ job contract. Corroborating timings from nb-bridge on AdomLapper and adom-lbr on winvm. Filed by the ah dock bar thread because the dashboards do not own /ai-threads/run-prompt.

Related: POST latency for run-prompt was measured at 1.85 s (AdomLapper) and 20.8 to 22.6 s (winvm), against a documented expectation of "well under a second". Same cold/slow-machine pattern, and worth a look while this is open.

3 Replies

John Lauer · 1mo ago

Correcting my own diagnosis above. Two more data points arrived after I filed this, and together they rule out the cold-tab-window explanation I opened with. The symptom is real and reproducible; my proposed cause was wrong.

What the original report claimed

That the 30 s hook window, measured from the submit click, is too tight for a cold first tab on a slow machine, evidenced by kicad's session identifying at 28.6 s against a ~37 s deadline.

What breaks that

pup-bridge, winvm, ah 1.0.190. Its send was identified fast and still failed:

moment	t
POST returned job `958ec70c`	15.3 s
submitted, sid `2137b834`	t+2 s
terminal `submit_unconfirmed`	t+18 s

A session id at t+2 s is nowhere near the window. If a tight deadline were the cause, this send should have passed comfortably. It did not.

And winvm is not simply broken: kicad's second click on that same VM reached working normally, minutes after its first click failed. So the box both fails and succeeds.

The other theory does not survive either

pup proposed that winvm's Claude tab is not signed in, so no SessionStart hook fires. I checked directly, GET /claude/conversation-state on winvm:

ready: true,  msgs: 8,  turns: 1,  input_count: 1,  answering: false

The tab is loaded, has a real conversation, and is ready. AdomLapper, where every send succeeded, reports the same shape (ready: true, msgs: 103, turns: 2). Sign-in state does not separate the two.

What is actually established

submit_unconfirmed occurs intermittently on winvm, on at least two independent dashboards (kicad, pup), with ah 1.0.190.
It occurs even when the session is identified within ~2 s, so it is not a race against the 30 s deadline.
The same box produces working on other sends, so it is not a permanently missing hook.
AdomLapper has not reproduced it: nb-bridge passed both clicks there, identifying sessions at 1447 ms and 2517 ms.
In every observed case the prompt did arrive and the AI did answer. The failure is in the reporting, not the delivery.

So: the UserPromptSubmit hook is intermittently not firing, or not being observed, on that machine, and the deadline is a red herring. I do not know the cause, and I would rather say so than send you after the wrong one.

Why it still matters at the same priority

Unchanged from the original report, and the reason I filed at all. submit_unconfirmed is terminal, so the shared panel resolves it as opened rather than delivered and tells the user "Sent, but delivery was not confirmed" for a prompt that was in fact delivered and answered. A user who believes it clicks again and double-sends. Whatever the root cause, a state that means "we could not observe the hook" should probably not present to users as a failed send when the tab, the session and the answer all exist.

The suggestion that survives from the original: let a late hook arrival upgrade an already-terminal submit_unconfirmed. That helps regardless of why the hook was missed. The other two suggestions I made assumed the timing theory and can be ignored.

John Lauer · 1mo ago

Two changes in Hydrogen 1.0.278 (insiders) aimed at exactly this symptom, plus what today's instrumentation showed.

What we saw on the laptop and ConfRoomROG today: the wake-heal reconnect-dialog watcher walked every editor webview every 30s under the CDP gate and, with many AI panels open, held that gate for 46s of every 76s. Everything that needed the editor queued behind it, including the delivery path. That walk is gone in 1.0.280 (the check now evaluates in the workbench document only, bounded, and only while the extension's tab stream is down).

For the hook itself: the hook script posted with a 2s curl cap and no retry, so a control API that was busy for a moment lost the UserPromptSubmit and the job ended submit_unconfirmed. 1.0.278 gives it a 4s cap and one retry. And a job that already ended submit_unconfirmed now flips to working/done when that session's hooks arrive late (job.late_hook names the hook), so a dashboard that keeps polling sees the truth instead of the hedge.

Leaving this open until a winvm run confirms; the ConfRoomROG runs on 1.0.280 (parked panel, Codex) all ended done with hooks at 15 to 17s.

John Lauer · 1mo ago

Closing. Two changes in 1.0.278 and 1.0.280 targeted this (the CDP-gate walk that starved the delivery path is gone), and no submit_unconfirmed on a delivered prompt has been reported since. Reopen with a job id if a dashboard shows the hedge again.