Stale answered ask card: clicking reports question response rejected: not-pending

[jilian-dsh]

Background

Regular user; local debugging with an AI assistant.

Issue: stale answer card after a resolved ask_user_question — clicking reports question response rejected: not-pending

After an ask prompt has been answered successfully, if the session happens to go through an event burst (subagent completion notification, hot reload, switching sessions around the same time), the client can lose the resolved frame: the answered card stays on screen, and clicking any option is rejected with question response rejected: not-pending (the host no longer has the question).

Evidence (local)

• The same dialog's host-side record existed the whole time: 10+ hours later, a custom-text submission on that same dialog succeeded — proving the host question was still pending and the rejected clicks were client-side stale cards, not a server-side state mismatch.
• We also fixed the engine-side trigger that was producing a cascade of prompts (that is the main fix); the client-side card residue is a separate hardening opportunity.

Suggestion

Client-side hardening for lost resolved frames: retry/align card state on reconnect, or reap answered cards via a timeout/async poll — so user clicks on an already-answered card are either ignored silently or reconciled, instead of surfacing not-pending.

[argszero]

Solid report — I traced the whole rejection path against rc.2 (HEAD b150a55). The not-pending rejection is the host being authoritative and correct; your diagnosis that the residue is client-side is right, and the source narrows the loss window precisely.

1. The host rejection is deliberate and must stay

• respond() (packages/host/apiproxy/src/api-proxy.ts:3609-3610) rejects not-pending when the rpcId is not in the pendingQuestions map.
• claimQuestion deletes the entry synchronously before resolving (:1298-1308), with the explicit design note "first claimant wins" (:1298). The comment at :1403-1406 (approvals) says the same: a settled id is not-pending before it can ever be re-accepted.
• So not-pending is the integrity backstop against duplicate/late answers. Silently ignoring it would be wrong — a genuinely-late answer must not be accepted twice. The fix belongs on the client: treat not-pending as "already handled" and reap the card, rather than surfacing it as an error.

2. The reconnect path is actually covered — the loss is a live-stream gap

• On a new mux connection the host replays still-pending questions with their STABLE rpcId (:3339-3343), and the comment there says exactly this: a reconnecting client can still answer them.
• Client-side, resync() clears the pending map (:436) and the baseline replay re-mints still-pending requests (:434, :504-509).
• So a full reconnect does NOT leave a stale card. Your scenario is the narrower case: the mux stream survives, but the question/resolved broadcast (:1304-1307) is missed while the view re-initializes mid-burst — hot reload re-mounting the UI, or switching sessions around the same time. The client's resolved handler (packages/client/runtime/src/client/sessions/session.ts:510-515) only settles an item it still holds; a card whose resolved frame never reached its view stays rendered, and its rpcId is long gone from the host map. Clicks then correctly get not-pending.

3. Fix shape (client-side hardening, matching your suggestion)

• Reap on not-pending: treat the not-pending receipt as an idempotent settled signal — drop the card silently (optionally reconcile the dialog's state to answered) instead of showing a rejection. This is the minimal, always-correct behavior regardless of which frame was lost.
• Reconcile on view re-init: after hot reload or re-entering a session on a live connection, compare rendered question cards against the session's replayed queue snapshot (the same baseline resync uses at :436-438) and reap cards whose rpcId is not in the still-pending set. This closes the gap for frames missed during the burst without weakening the host-side first-claimant-wins contract.
• Your engine-side cascade fix is the right root fix for the re-issue case; these two client rules cover the residue.

Your evidence that the host-side record stayed pending (custom text later succeeded) fits this exactly: the replayed/updated question carries a NEW rpcId (or the same one still pending), while the zombie card sends the OLD id. Reaping by rpcId-match against the live set is the correct discriminator.

[jilian-dsh]

Thanks for the thorough trace. We'll treat the two client-side rules as the upstream direction (reap on not-pending as an idempotent settled signal; re-init reap by rpcId match against the replayed still-pending set). Our engine-side cascade fix is already in place locally. Could the client hardening land in dsh-web? Happy to help verify with the shared repro steps (hot reload or session switch while an ask card is pending).