[bug] A stalled transcription hangs on "Transcribing…" forever and locks the composer — no timeout, no retry, no dismiss, reload is the only escape

[serge-ivo]

What the user saw

"when I was testing it, when it was transcribing it was taking forever"

A turn goes to Transcribing… and stays there. No error, no timeout, no way to give up. And while it is stuck the composer is readOnly — so the user cannot even type the message instead. The only escape is a page reload.

This is not the same defect as #420 (which is about mute deleting the words). Here nothing is deleted; the turn never resolves, and the UI is locked behind it.

Verified mechanism — four facts, each from the code

1. The transcription request has no timeout and no abort. packages/sdk/src/voice/stt.ts:344-351:

const res = await fetch(
  `${API}/v1/keys/proxy/api.openai.com/v1/audio/transcriptions`,
  { method: "POST", headers: { Authorization: `Bearer ${getToken() ?? ""}` }, body: form },
);

No signal. grep -c AbortController packages/sdk/src/voice/stt.ts → 0, and there is no AbortController or AbortSignal.timeout anywhere in packages/sdk/src/voice/ or packages/sdk/src/client.ts. The streaming branch (_readTranscriptionStream) reads res.body with no deadline either. The server side has none either — workers/api/src/routes/keys.ts (proxy at :162) has no AbortSignal/timeout.

So if the request stalls, the promise never settles.

2. Nothing else can resolve the turn. The whole failure apparatus hangs off onError (use-voice.ts:1225-1280) — and it is good: it classifies soft/mic-unavailable/real, writes dictate({type:"failed", note}), shows a notice, logs durably. A hang never reaches any of it, because onError is only ever called from a catch or a !res.ok. A request that never settles produces neither.

3. There is no watchdog. Dictation carries startedAt (machine.ts:254, set at :296 on endOfTurn). Grepping every consumer: the only reads are the reducer writing it. Nothing anywhere compares startedAt to now. The field that would make a timeout trivial exists and is unused.

4. The stuck bubble locks the composer and offers no way out.

• composer.ts:47 — readOnly: !!s.dictation && s.dictation.status !== "failed". transcribing is not failed, so the textarea is held. The doc comment above it says readOnly means "voice owns this turn" — a hung turn owns it forever.
• InstanceDetail.tsx:1164-1166 — Dismiss is rendered only when status === "failed". A transcribing bubble has no Dismiss, no Retry, no cancel.
• :1169 — it shows … under a spinning Loader2, indefinitely.

So: locked out of typing, locked out of dismissing, spinner forever. That is the "taking forever" you saw, and it is a hard lock rather than slowness.

On the deployment theory

Partly checkable, and I will not overstate it. Verified: there were 9 Deploy API Worker runs today between 02:50 and 04:51 UTC, several overlapping your testing window. Not verified: that one of them coincided with the stuck transcription, or that a Workers deploy can stall an in-flight proxied request at all (Cloudflare deploys are atomic; I have no evidence either way and did not test it).

The more useful point is that it does not matter. Deploy, cold start, flaky mobile radio, OpenAI stalling — every cause produces the identical unresolvable hang, because there is no deadline on the client. The fix is the same for all of them, and a deploy-specific error message would be guessing at one cause out of many. If a deploy-awareness banner is still wanted, that is a separate ticket and needs a real signal (e.g. a version/health probe), not an inference from a spinner.

What to do — cheapest first

1. A deadline on the request (small, fixes the hang). Wrap both the plain and streaming paths in AbortSignal.timeout(...) and route the abort into the existing onError, which already does everything right from there — the bubble becomes failed, keeps the words the live gate heard, keeps the recording, shows the note, and offers Dismiss. Suggested: ~20s to first byte. A distinct message is needed so it does not read as a user error: "Transcription timed out", not "Whisper failed: …".

2. A watchdog on startedAt (belt-and-braces). A request can also stall after headers, in the SSE read. A timer that flips a dictation still transcribing after N seconds into failed costs a few lines and uses the field that already exists. This is the one that guarantees the UI can never be permanently stuck regardless of what the network layer does.

3. Retry, and say which kind of retry. This is what the user actually asked for: "users need to see the message and know what to do — retry now or later." The clip is still in hand (lastAudioBlobRef / the blob passed to onAudio), so Retry is cheap and should be offered on the failed bubble next to Dismiss — re-POST the same blob. Distinguish the two cases in the note, because the right action differs:

• Retryable now (timeout, 5xx, network) → "Transcription timed out. Retry · Dismiss".
• Not retryable (401/400 bad key, audio too short) → say the reason and do not offer Retry; the existing parseUpstreamErrorDetail already surfaces OpenAI's own text.

4. Never hold the composer on a stalled turn. Even before (1)-(3) land, readOnly should not outlive a turn that is no longer making progress. Options: drop readOnly once transcribing exceeds a few seconds, or narrow it to dictating only. I would narrow it to dictating — the box needs holding while words are landing live into the bubble, but once the mic is closed and we are only waiting on a network call there is no reason a user cannot type. That is one boolean and it removes the lockout entirely, independent of every other fix here.

Alternatives considered and rejected

• Show a deploy banner when CI is running. Rejected as the primary fix: it addresses one hypothesised cause out of several, is unverified (see above), and leaves the hang in place for all the others.
• Auto-retry silently on timeout. Rejected: transcription costs the user's own OpenAI credit, and a silent retry of a 20s stall doubles the wait before they learn anything. Tell them, offer the button.
• Clear the bubble on timeout. Rejected: that is the [bug] A voice turn rejected as noise is erased along with the live capture — nothing survives, nothing is logged #377/[bug] Muting while a turn is transcribing deletes the words — the bubble is cleared and the in-flight transcript is then dropped or sent by an unrelated 800ms echo timer #420 failure mode — the words the live gate heard and the saved recording are the only surviving record of the turn. failed exists precisely so they survive.
• Timeout only on the server proxy. Rejected as sufficient on its own: it fixes the upstream stall but not a client-side network stall, and the client still has no deadline. Worth adding as well, not instead.

Acceptance criteria

• A transcription that never returns resolves to failed within a bounded time, with a note naming the timeout.
• The failed bubble offers Retry for retryable failures (timeout/5xx/network), re-sending the same audio; no Retry for 400/401-class failures, which state their reason instead.
• The composer is never held by a turn that is only waiting on the network — the user can always type instead.
• A stuck turn is recoverable without reloading the page.
• The timeout path writes a durable log row (reportClientError), excluded from the isConnectivityError skip so real stalls stay countable.

Regression risk

• A timeout set too tight would fail slow-but-working transcriptions on poor mobile networks, and the retry costs credit. Start generous (~20s) and check the durable log for timeout rows before tightening.
• Narrowing readOnly to dictating risks a user typing and sending while a transcript is still in flight, producing two messages. That is visible and intentional on their part, unlike today's silent lock — but the arriving transcript should then go to the composer rather than auto-send. Note this interacts with [bug] Muting while a turn is transcribing deletes the words — the bubble is cleared and the in-flight transcript is then dropped or sent by an unrelated 800ms echo timer #420 fix (3); the two should be decided together.
• composer.test.ts pins the composer binding rule and scans consumer trees; it will need updating and is the test that catches a wrong change here.

Related: #420 (mute deletes a transcribing turn — same pending-utterance state, different failure), #281 (the pending bubble and the failed status this relies on), #377 (words must survive a rejected turn), #387 (a giving-up path that produces no evidence of itself — same family).

[serge-ivo]

Update: the deploy correlation IS now evidenced, and the platform already has the message — it just renders badly

The reporter clarified the testing happened within the last hour. That made the window checkable, and it changes part of what I wrote above.

A deploy did disrupt the session — verified

GET /v1/admin/errors, correlated against gh run list:

03:54:20Z → 03:56:27Z   Deploy API Worker (success)
03:56:40Z               client:api | POST /v1/instances/bfc76603-…/chat → 503
                        body: {"error":"The service is updating — please try again in a moment."}

13 seconds after that deploy completed. And the affected instance's thread ends exactly there:

user: "Try again"
system: "⚠ The previous turn ("Try again") was interrupted before its reply was saved."

So PAGS already detects this and already has the right words for it. workers/api/src/index.ts:187-192 — app.onError checks isTransientInfraError(err) and returns 503 {"error":"The service is updating — please try again in a moment."} rather than logging a bogus 500. That is good design and it is working.

I was wrong to treat "show an error during deploys" as unverified speculation. It is a real, already-implemented behaviour. What is wrong is what the voice path does with it.

The defect: the deploy message reaches the user as raw JSON, blamed on OpenAI

stt.ts:353-357 on a non-OK response:

const detail = parseUpstreamErrorDetail(await res.text().catch(() => ""));
this.onError(`Whisper error ${res.status}${detail ? `: ${detail.slice(0, 300)}` : ""}`);

And audio.ts:187-194:

export function parseUpstreamErrorDetail(rawBody: string): string {
  if (!rawBody) return "";
  try {
    return (JSON.parse(rawBody) as { error?: { message?: string } })?.error?.message || rawBody;
  } catch { return rawBody; }
}

Two different error envelopes, one parser. OpenAI returns {error: {message: "…"}}. PAGS returns {error: "…"} — error is a string, so ?.error?.message is undefined and it falls through to || rawBody.

So during a deploy the user's toast reads:

⚠ Whisper error 503: {"error":"The service is updating — please try again in a moment."}

Raw JSON, prefixed "Whisper error", attributing a PAGS redeploy to OpenAI. The one message written specifically to be reassuring is delivered in the least reassuring form available, and it points the user at the wrong vendor.

Added to the fix list (cheap, independent of the timeout work)

0. Teach parseUpstreamErrorDetail the platform's own envelope — accept error as a string as well as {message}. One line, and it improves every !res.ok message, not just this one.

0b. Do not prefix a platform error with "Whisper". When the response comes from our proxy rather than upstream, say so. A 503 with our own envelope is distinguishable at stt.ts:353. Suggested text: "ProAgentStore is updating — try that again in a moment.", with Retry offered (this is the most retryable failure there is).

What is still not established

That a deploy caused the specific hang described ("taking forever"). A 503 is a fast failure and would have produced the toast above, not a spinner. So the hang and the deploy are most likely two separate events in the same session. The hang defect stands exactly as filed — no timeout, no watchdog, composer locked — and is unaffected by this update.

Also worth noting for whoever picks this up: the durable log was hard to read during this investigation because ~97% of it is one repeating cron failure — filed separately as #423.

[serge-ivo]

Correction: I ranked the two timeout fixes in the wrong order — the first one does not protect the default path

Re-reading my own proposal against stt.ts:

The default STT model streams. config.ts:123 resolves sttModel to DEFAULT_STT_MODEL (gpt-4o-transcribe, per the comment at :7 and :121-122), and stt.ts:337 branches on it:

const streaming = this.model !== "whisper-1";
…
if (streaming && res.body) { await this._readTranscriptionStream(res.body, blob); return; }

So for almost every user, the request returns headers quickly and the transcript arrives over an SSE body afterwards.

That breaks fix (1) as I wrote it. I suggested "~20s to first byte" via AbortSignal.timeout on the fetch. A fetch-level deadline fires on time-to-response, which on the streaming path is fast and successful — the stall happens later, inside _readTranscriptionStream, reading a body that never delivers another chunk and never closes. An AbortSignal.timeout on the fetch would not have caught the hang the reporter actually experienced, because they were on the streaming model.

Corrected ranking

1. The startedAt watchdog is the primary fix, not the backup. It is the only one that covers a stall at any point — before headers, mid-stream, or after the last chunk — because it watches the outcome (dictation.status === "transcribing" for longer than N) rather than one transport event. Dictation.startedAt (machine.ts:254) already exists and is still read by nothing.
2. The fetch deadline is the secondary fix, and it should be a stall timeout on the stream reader (no chunk for N seconds), not a first-byte timeout — plus a plain AbortSignal.timeout on the non-streaming whisper-1 path, where first-byte is the right signal.

Both still route into the existing onError, which already does the right thing (bubble → failed, words and recording preserved, note shown, durable row).

Unchanged

Fix (4) — narrowing readOnly to dictating — remains the cheapest single change and the one that removes the composer lockout independently of any timeout work. Its interaction with #420 fix (3) still stands as written.

Why this matters beyond the ordering

An implementer taking (1) first, shipping it, and testing on the default model would see the hang persist and reasonably conclude the diagnosis was wrong. The watchdog is both the more complete fix and the one that can be verified without contriving a pre-headers stall.

[serge-ivo]

Cross-note from #427, which was the same shape in the chat path — a non-streaming request under a wall-clock ceiling, where the ceiling measured the wrong thing. Not touching the voice files; leaving the pattern here since #427 named this issue as the sibling.

Shipped in d5c6d1a / efe285a:

• workers/api/src/lib/ai-deadlines.ts — the deadline table. One number became three, because "still working" and "gone away" are different facts: first token (nothing yet ⇒ outage, a retry genuinely helps), stall (silence since the last progress, re-armed per chunk), total (an absolute ceiling so a runaway still ends). If the STT path has any notion of incremental progress — and gpt-4o-transcribe streams partials over SSE, so it does — the stall deadline is the one that matters and the total is just a backstop.
• deadlineMessage(kind, budgetMs) — the user-facing sentence is per kind, and pure, so it is testable. The concrete lesson from [bug] Chat times out at 25s on the tool loop's second round — a 4096-token cap under a 25s non-streaming ceiling is an impossible combination #427: AI request timed out (25s) told the user to retry a deterministic failure; they did, on their own credit, and it failed identically six minutes later. first-token invites a retry; total says "sending the same message again will fail the same way" and names what does work. A test asserts the total string never regains "try again".
• The consistency test is the actual deliverable. generationBudgetMs(CHAT_MAX_TOKENS) <= AI_TOTAL_TIMEOUT_MS in ai-deadlines.test.ts. The bug was never one wrong number — it was two numbers in two files that nothing related, each defensible alone. If the STT path has an analogous pair (an audio-length or model cap on one side, a timeout on the other), that assertion is worth copying more than any of the code is.

Two implementation notes that cost time and would cost it again:

1. Collect the stream server-side, behind the existing function signature. [bug] Chat times out at 25s on the tool loop's second round — a 4096-token cap under a 25s non-streaming ceiling is an impossible combination #427's regression note called this out and it was right — callers saw literally no change, because lib/anthropic-stream.ts rebuilds exactly the body the non-streaming endpoint returned.
2. Never return the partial. A stream that ends without its terminal event produced some text, and handing that back is [bug] Every chat reply is capped at 1024 output tokens and truncation is never reported — stop_reason is read by nothing #397 with a new cause. It fails honestly instead — and the same for a tool_use whose arguments arrive truncated.

One testing gotcha, in case it saves an hour: vi.useFakeTimers() deadlocks these tests. Real WebCrypto (decryptKey) does not resolve under a faked clock, so the request never reaches the read loop that would arm the timer. vi.mock the deadline module to shrink the constants instead, in a file of its own — see workers/api/src/lib/user-ai-stall.test.ts. Real timers, real streams, real reader; only the two numbers change.

[serge-ivo]

Shipped in b53ce39, live on proagentstore.online/console/ (CI green, Host + API workers deployed).

All four fixes plus your 0/0b update. Ordered as you filed them.

1. Two deadlines, not one. 20s to first byte and 45s for a stream that answers and then stalls mid-SSE — the second case is invisible to the first. AbortController rather than AbortSignal.timeout, because the stream deadline has to replace the first-byte one once headers arrive, and because the abort has to be distinguishable from a real network error: reporting it as "Whisper failed: AbortError" would name our own symptom, blame the user's vendor, and hide that Retry is worth offering.

2. The watchdog, on startedAt — with a correction. startedAt is the utterance's, not the clip's, and reduceDictation's endOfTurn branch preserves it. A deadline hung off it fires on any turn longer than the timeout, and the mic may legitimately stay open for maxDictationMs. So Dictation gains transcribingAt, stamped at end-of-turn, zeroed when the turn resolves, and re-stamped by a new retry event. Set longer than both network deadlines so the specific message wins the race.

3. Retry, and which kind. isRetryableVoiceError splits it exactly as you specified — timeout/5xx/network/deploy get the button, 400/401-class state their reason and get none. Conservative about failures it has never seen, because a dead Retry costs the user's own credit to discover. Not automatic, for the reason you gave.

4. readOnly narrowed to dictating, which was your recommendation and is the right one. The race you flagged is real but it is visible and deliberate on the user's part, and a transcript landing after they typed goes to the composer rather than auto-sending (classifyResult) — so the worst case is two visible drafts, not a silent double-send. That interaction with #420 fix (3) was decided together, in the same batch, as you asked.

0 / 0b — the deploy message. Verified and fixed. parseUpstreamErrorDetail knew one envelope; the string-vs-object shape of error is the discriminator and is now used. Our own 503 says "ProAgentStore is updating — try that again in a moment." with Retry; OpenAI's reasons are unchanged; nothing prints raw JSON at anyone. Tests assert the observed message specifically — no Whisper, no braces.

One consequence worth flagging

Your acceptance criterion "excluded from the isConnectivityError skip" was necessary, not belt-and-braces: that helper matches /timed? ?out|aborted/, so without an explicit exemption the one failure this ticket exists to make countable would have been filtered out by the thing that hides network noise. Exempted, and those rows are the evidence needed before the 20s deadline can safely be tightened.

Verified / not verified

• Verified: 6,606 unit tests, full CI bar, 249 e2e specs (chromium + webkit). The timeout tests drive a fetch that genuinely never resolves — with signal removed they hang and fail, which I checked rather than assumed. composer.test.ts updated, including a new property test that no status other than dictating may hold the input.
• Verified live: the production console bundle carries Transcription timed out, ProAgentStore is updating, canRetryTranscription and transcribingAt.
• Not verified end-to-end: a real stalled upload against a real network. The deadline path is covered by unit tests; the watchdog is not exercised outside them.

platform-docs/voice.md now documents the timeout and Retry for users; /docs/voice/ is live with it.

Not done

Your note that the server proxy should get a timeout as well ("worth adding as well, not instead") is not in this change. workers/api/src/routes/keys.ts still has no AbortSignal. Left deliberately: it is a different file, a different failure (an upstream stall the client deadline already covers from the user's side), and it belongs with whoever is working the proxy. Leaving this issue open would be the wrong signal — everything filed here is done — so it should be a fresh ticket if it is still wanted.

[serge-ivo]

Closing — all five acceptance criteria verified against the code on main, not against the closing comment.

b53ce39 is on origin/main; CI + Deploy Host/API green on the batch head 2f33801.

#	Criterion	Verdict
1	Never-returning transcription resolves to failed in bounded time, note names the timeout	MET — stt.ts:27-31 (20s first-byte / 45s stream), AbortController stt.ts:385-399, deadline swap :410-413, abort reported as the timeout not AbortError :430,:489; watchdog use-voice.ts:70,:1703-1713 off Dictation.transcribingAt (machine.ts:360, stamped :404, zeroed :410, re-stamped by retry :411-415)
2	Retry for retryable failures, re-sending the same clip; none for 400/401, which state their reason	MET — canRetryDictation use-voice.ts:1732, retryDictation :1723-1728, clip held stt.ts:360, isRetryableVoiceError checks 4xx first (convo.ts:884-891); UI InstanceDetail.tsx:1212-1215, CopilotView.tsx:438-441
3	Composer never held by a turn only waiting on the network	MET — composer.ts:50 is now exactly status === "dictating", with a property test asserting the held set is exactly that one status
4	A stuck turn is recoverable without a reload	MET — watchdog flips transcribing → failed (use-voice.ts:1708), Dismiss renders on failed
5	Timeout writes a durable row, exempt from the isConnectivityError skip	MET — use-voice.ts:1360; the exemption is load-bearing, client.ts:24 matches /timed? ?out|aborted/

Your 0/0b update is verified too: parseUpstreamErrorDetail discriminates the string-vs-object error shape (audio.ts:192-212) and our own 503 reads "ProAgentStore is updating — try that again in a moment." (:224-232). Production console bundle carries Transcription timed out, ProAgentStore is updating, canRetryTranscription, transcribingAt.

Two deviations from your spec, recorded rather than glossed

1. The stream deadline is an absolute 45s cap armed once (stt.ts:412), not a per-chunk stall timer. Your correction comment specified a stall timeout re-armed on each chunk; _readTranscriptionStream (:443-462) does not re-arm. Criterion 1 still holds — the hang is bounded — but a stream that stalls at second 5 waits the full 45s, and one trickling a byte every 40s is failed rather than kept alive.
2. A partial is salvaged as a final when the abort fires after some text arrived (stt.ts:480-485). Words survive, so no criterion is violated, but that stall emits text and logs no timeout row — so those stalls are not countable, which is the opposite of the "never return the partial" lesson in the [bug] Chat times out at 25s on the tool loop's second round — a 4096-token cap under a 25s non-streaming ceiling is an impossible combination #427 cross-note, and it erodes the evidence criterion 5 exists to collect.

Neither is a reason to hold this open; both are worth a ticket if the 20s/45s numbers are ever to be tightened.

Not done, correctly

The server-proxy deadline — workers/api/src/routes/keys.ts still has zero AbortSignal/AbortController occurrences, verified. It was not an acceptance criterion: your checklist has five items, none server-side, and the proxy appears only under Alternatives considered and rejected ("worth adding as well, not instead"). The closing comment's characterisation is accurate. Needs a fresh ticket if still wanted.

Not verified, and not claimed

No test exercises the watchdog useEffect itself — only its data dependency (reduceDictation's transcribingAt); there is no use-voice test file. And no live stalled upload against a real network. Both were stated as unverified in the closing comment and I am repeating rather than upgrading that.