[Bug] ask_user_question hangs indefinitely when no tab renders the question — no timeout; manual stop surfaces misleading ASK_ABORTED

[yeruizhi]

Bug: ask_user_question hangs indefinitely when no browser tab renders the question — no timeout, no notification, only manual cancel returns ASK_ABORTED

Summary

When ask_user_question is called while the owning Web UI tab is not actively rendering the question (page closed, tab backgrounded overnight, mux connection dropped), the tool call hangs indefinitely with no timeout, no re-notification, and no visible error. The UI keeps showing "running in progress" for the whole time. The only way out is for the user to manually press the stop button, which then surfaces a misleading ASK_ABORTED error ("ask_user_question was aborted before the user answered") — implying an abort happened by itself, when in fact the question was never rendered to anyone.

Evidence (from a real session event log)

Two ask_user_question calls in the same session, same code path:

call	invoked at	result at	wall time
#1	18:41:14	18:46:48	5 m 34 s (normal: user was at the keyboard)
#2	23:58:27	08:18:03 (next day)	8 h 20 m 36 s

For call #2:

• tool/call seq 126534 at 23:58:27 with callId; after that there is no tool/result, no step/end, no turn/end for over 8 hours — the loop stays "running".
• The only subsequent event is tool/result seq 126535 at 08:18:03 (immediately after the user clicked the stop button) with content:
  Error: ask_user_question was aborted before the user answered
• No question/resolved, no agent/cancel-requested-attributed event, no timeout event precedes it. The abort came from the user's manual stop.

Root cause analysis

1. The question is rendered only by the live browser composer takeover

The browser half mounts QuestionComposer via a slot injected into the conversation composer chain:

• packages/client/ui-user-questions/src/client/index.ts — ctx.slots.inject('conversation.composer', ...) with selector selectQuestion matching interactions.find(i => i.kind === 'question').
• The host mints the pending wait from the question/requested mux frame: packages/client/runtime/src/client/sessions/session.ts:500 → new PendingWait('question', ...).

If no browser tab is connected to that session's mux, or the tab is not rendering the composer chain (closed / backgrounded / disconnected), nobody ever sees the question — the host-side pending entry exists, but there is no viewer.

2. Re-delivery only happens on mux (re)connect — not on a live-but-inactive tab

On a fresh mux subscription the proxy replays pending questions (packages/host/apiproxy/src/api-proxy.ts:3436). But a tab that stays open and connected while inactive does not re-render the question — the frame was already delivered once and consumed into a PendingWait that nothing displays. There is no heartbeat / re-ping / re-claim.

3. No timeout or escalation exists anywhere in the pending-question lifecycle

• Browser side: packages/client/runtime/src/client/sessions/pending.ts and session.ts contain no timeout/expiry for PendingWait.
• Host side: packages/host/apiproxy/src/api-proxy.ts:1376 keeps the pendingQuestions entry until aborted; nothing expires it.
• The service seam (packages/interaction/user-questions/src/index.ts) has no deadline either — ask() blocks on this.provider.ask(request).

4. The stop button produces a misleading error

The user's manual stop runs agent.cancel({ kind: 'user' }) (api-proxy.ts:2631), which aborts the turn signal; the pending ask then throws ASK_ABORTED (user-questions/src/index.ts:93-95; api-proxy.ts:1382-1386). The UI comment in packages/client/ui-tool/src/client/tool/toolviews/ask-question-row.tsx:51 literally labels ASK_ABORTED as "a turn interrupt landing while the question was pending" — so the error is correct as an abort report, but it is triggered by the user's own manual cancel, not by anything that happened with the question itself. From the user's perspective the session showed "running" for 8+ hours with no question visible and no error, and the eventual message reads like an internal abort rather than "you had to cancel a hung question".

Suggested fixes (open to maintainers)

1. Timeout on pending questions. Give PendingWait('question') (and the host pendingQuestions entry) a bounded lifetime (e.g. 5–10 min). On expiry, surface a visible "question went unanswered / re-ask" state in the UI and/or let the model know the ask expired, instead of hanging forever.
2. Re-notify on inactivity. If a session has a pending question and its mux has no active viewer (or the tab is backgrounded), re-emit question/requested on reconnect — and optionally on visibilitychange/focus so a backgrounded tab re-shows the question when the user returns.
3. Better UX on manual stop. Distinguish "user manually cancelled a hung question" (ASK_CANCELLED) from "turn interrupted" (ASK_ABORTED) in the summary the user sees, so a manual stop of a never-visible question reads as cancelled, not aborted.

Environment

• DeepSeek Harness, source at deepseek-ai/deepseek-harness 47f943859b (feat/npm-public merge)
• Web UI (dsh web), standard agent preset
• Occurred when the question was asked while the browser tab was not actively displaying the session (overnight gap); reproduced once, same-session control call behaved normally.

Steps to reproduce

1. Start dsh web, open a session.
2. Ask the model something that makes it call ask_user_question (e.g. a choice between options).
3. Before answering, close the tab (or background it and leave the machine overnight).
4. Reopen / return later: the session shows the turn "in progress" forever; no question UI appears; no error is logged.
5. Click the stop button: only then does the tool result appear as ASK_ABORTED.

[yeruizhi]

修复已完成(补丁已就绪)

核心修复已实现并测试,分支已推到 fork:

fork 分支: yeruizhi/deepseek-harness@fix/ask-user-question-timeout

改动(6 文件, +95/-10):

1. host 端: PendingQuestion 增加有界生命周期定时器(ApiProxyDefaults.questionTimeoutMs,默认 10 分钟,0 禁用)。到期后以新 timeout outcome 结算,并以 ASK_TIMEOUT 拒绝——循环继续,模型可重问,不再无限"进行中"。
2. wire: question/resolved 的 outcome 联合增加 timeout(zod schema + 类型)。
3. UI: ASK_TIMEOUT 显示为"问题超时未回答"(与 ASK_ABORTED 相同的 stopped 语义);zh/en 文案已加。
4. 测试: +2 用例(超时拒绝 + deadline 前应答不误超时);packages/host/apiproxy 全套 20 文件 / 376 测试通过。

说明: 官方仓库当前禁用了 issues 和 pull requests(与 CONTRIBUTING 声明一致),无法直接提交 PR;若未来开放 PR 通道,此分支可直接提交。附带独立可装的 guard 插件 yeruizhi/dsh-ask-user-timeout 实现了同样语义,可立即使用。

[TerrysPOV]

Confirming this still reproduces on 0.1.1-rc.2 (Node v22.23.2, Ubuntu 22.04.5) — hit it twice
in 48 hours, once for 13.5 hours before anyone noticed. Same shape as your call #2.

Adding one thing your event-log analysis can't show, in case it helps whoever picks this up:
at the runtime level there is nothing to find. A Node diagnostic report (SIGUSR2) taken against
the stalled process and diffed against a healthy baseline from the same process earlier that day:

type       healthy  stalled  delta
async            3        3      0
timer            1        1      0
pipe             1        1      0
process          1        1      0
tcp              6        4     -2      ← fewer, not more
fs_event        15       29    +14      ← unrelated file watchers

javascriptStack empty, process CPU ~0.06s per 10s (client polling only). Nothing is pending —
tcp actually goes down. Because it's a bare promise with no I/O behind it, every conventional hang
triage comes back clean: ps/wchan show ep_poll, ss shows no stuck socket, there's no blocked
syscall, no busy loop, and --trace-uncaught prints nothing. Confirms the diagnosis from the other
side: nothing is waiting on the runtime, the turn is waiting on an answer that can never arrive.

That's also why it's so expensive in practice — there is no signal at all. No error at any log
priority, no CPU, no crash, no alert. The UI spinner is the only indication, and if nobody is looking
at the tab it simply burns hours.

Interim mitigation for anyone else bitten by this, until there's a timeout: a 2-minute watchdog
that flags a turn as stalled when a session.prompt was logged ≥N minutes ago and nothing except
polling traffic has been logged since, then fires SIGUSR2 for a report. Crude, but it caught our
second occurrence automatically at the 10-minute mark instead of the next morning.

Strong +1 on the timeout in #2544's suggestion 1. Worth noting the same no-timeout pattern shows up
in #4926 and #3588 — from the outside it reads less like three bugs and more like a missing
convention for bounding waits on anything that depends on a client being connected.

[yeruizhi]

Thanks @TerrysPOV — this is exactly the kind of follow-up that turns a bug report into something actionable, and your SIGUSR2 diff shows the half my event-log analysis never could.

The "bare promise with no I/O behind it" point deserves emphasis for whoever picks this up: it means detection cannot happen at the runtime level — every conventional hang triage comes back clean, as you demonstrated — so the only correct place to bound this is the protocol layer, i.e. a deadline on the pending question itself. Which also explains why the fix is small: there is nothing to unwind, just a timer that never existed.

Your watchdog write-up is a genuinely useful interim mitigation — catching a stalled turn at the 10-minute mark instead of the next morning is the difference between an overnight run that finishes and one that burns a day.

For anyone who wants bounded-wait behavior today: dsh-ask-user-timeout implements the same semantics as an installable plugin — it wraps ask_user_question with the same deadline() primitive the shipped timeout-policy guard uses, returns a structured, model-visible ASK_TIMEOUT result on expiry (default 10 min, configurable via timeoutMs), and leaves the loop free to continue or re-ask. The equivalent host-side patch also still sits on the fork branch linked above, ready to PR if that channel ever opens.

+1 on reading #4926 / #3588 together with this one as a missing convention — "anything that waits on a connected client needs a bound" feels like it belongs in the plugin authoring guide, not scattered across three threads.