Bug + fix: ask_user_question / approval card never renders after a reconnect (pending wait cleared by resync race)

[kaywow]

Summary

ask_user_question (and approval prompts) can intermittently fail to render their card in the web UI while the tool call stays blocked. The observed symptom is "stuck — no question card, no tool result"; pressing Stop then surfaces user abort. The host has the question pending and is correctly waiting for a human answer, but the browser never renders the card to answer.

I traced this to a reconnect race in the client runtime and prepared a fix with a deterministic regression test. Since external PRs aren't accepted (per CONTRIBUTING.md), I'm filing it here for the team's attention. Full diff on a fork branch: master...kaywow:fix/web-question-reconnect-race

Root cause

On reconnect:

1. the mux stream reopens and the host replays still-pending question/requested / approval/requested frames (same rpcId), which re-mint PendingWaits on the client — before onConnected fires;
2. onConnected then drives Session.resync(), which unconditionally ran this.pending.clear().

That ordering wipes the just-replayed wait, leaving the host blocked on an answer with no client-side wait to render. The two code comments already disagree: session.ts assumed "clear first, replay re-mints", while connection.ts documents "reconnect replays flow from stream open, ahead of onConnected".

Fix

Move the clear to generation death:

• add Session.clearPendingInteractions() — drops all pending waits;
• SessionManager.handleDisconnected() calls it for every instantiated session — this runs before the next generation's mux replay can arrive;
• Session.resync() no longer clears pending, so it cannot race the replay.

Stale waits (resolved while disconnected) are still dropped — now at disconnect instead of reconnect — and still-pending waits are re-minted verbatim by the replay. Fixes both question and approval waits (they share the same pending map). Files touched: packages/client/runtime/src/client/sessions/{session,manager}.ts.

Reproduction (deterministic)

In packages/client/runtime/tests/session.client.spec.ts:

1. open a session;
2. feed a question/requested frame (the reconnect replay);
3. call resync();
4. assert the wait survives.

Before the fix this fails with expected [] to have a length of 1.

Verification

• packages/client/runtime suite: 346 tests pass (includes new regression + manager-level tests).
• pnpm check:ci (ci-primary, Node 22.23.2): 50/52 gates pass. The two failures are unrelated to this change: test:snapshot leaks a node:sqlite ExperimentalWarning into stderr on Node 22, and knip passed in isolation (transient during the full run).

[Start-Gao]

Desktop confirmation: backgrounded tab + silent WebSocket death matches your resync-race analysis (3 failures + 1 control)

Environment: Windows 11 25H2, Node.js 24.14.0, dsh 0.1.0-rc.7 (global npm install), desktop Chrome (not mobile/remote).

Failures (long background ~1.5h each): the question/approval card was dispatched while the browser tab was backgrounded; on return the UI showed "waiting for answer / Deep diving..." with an empty composer takeover area. The card only appeared after a manual page refresh (reconnect + mux replay of the still-pending question/requested frame). Session log forensics (decoded .zstd):

Sample	tool/call	tool/result	Await gap	On return
#1	18:51:50	20:26:33	1h35m	no card until refresh
#2	20:43:47	22:08:33	1h25m	no card until refresh
#3	~22	after refresh	—	no card until refresh

All three tool calls/results carry isError=false (protocol layer clean); no question-specific events persist in the session log (pending waits travel the socket channel). Consistent with your finding that question frames are pushed only to the currently-online mux queue plus replay on mux-open.

Control (short background ~minutes): a 4th card rendered normally on tab return without refresh — so the long background/silent-disconnect window is required, matching the resync race you identified (replay arrives before onConnected and gets wiped by Session.resync()'s unconditional pending.clear()), plus the missing heartbeat gap from #3020.

Verdict: the bug family is confirmed on the desktop client as well; I support your fix and #3020's server-heartbeat approach. Refresh/reconnect remains the only user-side recovery until upstream adopts a fix.

[denial123789]

I verified the rc.7 ordering and combined it with the companion liveness failure in #3020. They are independent layers behind the same missing-card symptom: the Host keeps a stable-rpcId question/approval in its pending registry and replays it on mux open; a silent half-open WebSocket can prevent that new generation entirely, while a real reconnect can deliver the replay before onConnected, after which Session.resync() clears the newly minted client PendingWait. A complete repair therefore needs both bounded socket liveness and generation-scoped client cleanup at disconnect—not inside resync. The operator recovery must also preserve the consent boundary: hard-refresh once to recover the authentic request; if it does not reappear, cancel the turn and ask again rather than posting a synthetic response. I wrote the two-chain trace, evidence bundle, safe recovery, and twelve regression gates here: https://sandbaseai.github.io/deepseek-harness-handbook/missing-question-card.html

[panin1990]

Independent confirmation on a physical iPhone (iOS 26, Chrome, via a reverse proxy), reached separately before I found this thread — I landed on the same root cause and the same fix shape, which I hope is useful corroboration.

Update — this appears to be resolved in dsh-v0.1.2-alpha.2. I checked the tag after posting: the whole mechanism is gone. No PendingWait, pendingQuestions, question/requested or pending.clear() anywhere in the tree. Pending interactions now live in PendingInteractionDomain (packages/client/ui-session/src/client/index.ts:69), Session.resync() is history-only (packages/api/session-controller/src/client/sessions/session.ts:372), and handleConnected() only refetches lists (.../sessions/manager.ts:788) — so nothing clears interaction state after the replay. Stale waits are aborted per-delivery when the generation dies (packages/api/gateway/src/client/remote-events.ts:171). The race is structurally impossible in that design. Everything below is against 0.1.1-rc.2 and is kept for the record / for anyone still on it.

Why it reads as a phone-only bug. A desktop tab holds its socket for hours, so resync() rarely runs. A phone drops it on every screen lock and Wi-Fi↔LTE handover, so the card is lost on essentially every unlock. Answering the same question from a desktop works, which sends people looking at mobile CSS instead of the reconnect path.

Deterministic reproduction. context.setOffline(true) does not reproduce it — it leaves an established WebSocket open, so no reconnect happens. The socket has to actually close:

for (const s of sockets) if (s.readyState === WebSocket.OPEN) s.close()

Frame trace from a real run (times relative to that stream's open):

62.29 FRAME events.mux question/requested rpc=69aa4299   <- card rendered
 1.21 WS-CLOSE events.mux                                 <- socket dropped
 1.69 WS-OPEN  events.mux                                 <- reconnected
 1.71 FRAME events.mux question/requested rpc=69aa4299   <- replayed, same rpcId
      -> card still absent; pending was cleared after the replay

The host does its part correctly; the state was lost on the client afterwards.

One addition to your fix, from testing a version of it — still relevant to anyone backporting it to 0.1.1.x. Clearing on handleDisconnected alone leaves a narrower window open. emitState is deduplicated (if (this.lastState === state) return) and emitState("connected") only runs on the success path, so across a burst of failed reconnect attempts — mux opens and replays, then the readiness handshake fails — onStateChange("reconnecting") fires once while the stream opens and replays several times. If a question is answered elsewhere between two such attempts, the wait re-minted by an earlier attempt survives into a generation whose replay no longer includes it, and becomes a card that cannot be answered (respond() → not-pending).

An exact per-generation marker already existed on the wire: the host pushes session/subscribed for every session at mux open before the pending replay, and the frame queue is FIFO — so clearing there is generation-exact and immune to the dedup. Keeping the disconnect clear as well is still worth it: it drops the card as soon as the socket dies, rather than leaving an answerable-looking card over a dead connection.

A related detail worth stating explicitly, since it's the reason "just delete the two lines" was not equivalent: question/resolved is broadcast only to currently-connected mux queues (claimQuestion deletes from pendingQuestions, then broadcasts). A client that was offline when a question was answered elsewhere never learns it died, and mux-open replay iterates pendingQuestions, which no longer holds it. So the replay is the only authority on what is still pending — which is exactly why the clear had to happen before it, as you proposed, rather than being removed.

I ran both variants as a local client-side patch against 0.1.1-rc.2 for a couple of days on a phone; questions survived lock/unlock cycles reliably.

Upvoted — thanks for the thorough trace and the prepared fix.