【Bug】Web UI shows no feedback (no thinking, no tool calls, no message receipt) while the agent is busy in a long tool call; all content floods in at once when the turn ends

[RendezvousWithFlowers]

Environment

• DSH version: @deepseek-ai/dsh 0.1.0-rc.6
• Browser: Microsoft Edge 151.0.4129.59 (64-bit, Chromium 151.0.7922.72)
• OS: Windows 11 Version 24H2 (Build 26100.1742)
• Deployment: local dsh web (http://127.0.0.1:3080)

What happens (user-visible symptom)

1. The agent starts a long-running tool call (e.g. a background job monitor waiting on a multi-minute job_output).
2. During that wait, the UI shows nothing new: no "Think" row, no tool-call row, no status like "agent is still working".
3. If I send a message during this window (even a trivial one like "are you stuck?"), there is zero feedback — no echo of my message, no queued indicator. The message feels swallowed.
4. When the agent's turn finally ends, everything appears at once: the answer to the queued question plus a burst of the agent's messages. Sometimes the page appears frozen for a while and then a big block of content pops in.

This makes it impossible to tell whether the agent is alive during long operations.

Repro steps

1. Start a session and ask the agent to run something that blocks on a long background job (e.g. monitor a training run, or a job_output call with a several-minute wait).
2. While the tool is running, observe the conversation view: nothing updates.
3. Type a simple question and press Enter: no visual receipt of the message.
4. Wait for the turn to finish: the queued answer and all pending content render in one burst.

Evidence

Message RPC payload captured while sending during the busy window (the user message gets queued with no UI acknowledgement):

{
  "kind": "user",
  "rpcId": "cc6a1a17-da5a-4450-9a8e-1774f448b691",
  "clientTimeZone": "Asia/Shanghai"
}

Root-cause hints (from reading the shipped client code)

I inspected the installed @deepseek-ai/dsh-client-ui-conversation and dsh-client-connection packages:

• The conversation view does register reasoning rows ("Think" disclosure, ReasoningRow) and tool-call chat nodes (tool-call node driven by tool/call / tool/result events), so the components exist.
• During a long tool call no new SSE events are produced by the host, so the UI legitimately has nothing new to render — but there is also no static "still running" affordance for the in-flight tool row (e.g. an elapsed-time "running for N minutes" state), so a long silent tool reads as "hung".
• AssistantMarkdown has a guard (if (!(streaming || interrupted || blocks.some(b => b.kind !== "tool-call"))) return null;) which hides assistant steps that contain only reasoning once settled — thinking text is not visible after the step completes unless there is a text block.
• Busy-turn input goes to a queue (queue/steer mechanism, BUSY_ENTER_BEHAVIORS), but the queued item and its dock are easy to miss; the sent message has no obvious immediate echo.

What would help (suggestions)

1. Always render an in-flight indicator on the active tool row, with elapsed time (e.g. "waiting on job_output … 4m 12s"), so a long silent call never looks like a hang.
2. Immediately echo user messages sent while busy (even as a pending/queued bubble), with a clear queue badge, instead of silent acceptance.
3. Keep reasoning blocks visible (or at least their summary line) after the step settles, not only while streaming.
4. If a turn is interrupted or queued behind a long tool, show a small status line ("your message is queued; agent will answer after the current step").

Thanks for the great tool — this is the one rough edge that made long agent sessions feel unresponsive.

[yun520-1]

从事件流契约看，这个症状对应三条链路，建议逐条排查

我在本地部署 DSH（Linux + pnpm 源码启动 + nginx 反代，0.1.0-rc 系列）时读过这套事件流代码，先说几个代码里能看到的事实，再说怎么排查。

代码事实（packages/host/apiproxy/src/api/events.ts）

1. mux 流（全会话聚合）：session 打开时发 subscribed 控制帧，重放仍 pending 的 approval/question，再透传 session 事件。tool/call 事件带 render-intent（ToolCallView），设计上事件一到 UI 就能渲染"正在调用工具"。
2. host 流：session 创建/销毁、running-status 翻转、workspace 变更。UI 靠它知道 agent 是否在跑。
3. session/queue：用户消息排队时是 placement: 'queued' 条目，设计上 UI 应显示排队态。
4. mux 流是 RPC 方法 mux()（api-proxy.ts:3430），muxQueues 维护所有连接消费者，事件经 queue.push(envelope) 逐帧推送。

按这个契约，"长工具调用期间 UI 无任何反馈 + 发消息无回执"说明三条链路至少有一条没到 UI。代码层面能确认的是契约存在，不能确认的是实际运行时哪条断了——这需要排查，不是读代码能断言的。

排查步骤

① 先看 mux 流有没有推帧（区分"没推送" vs "推送了没渲染"）：

• Web UI 的 Network 面板找 mux RPC 长连接，跑长工具调用观察帧到达
• 调用开始有 tool/call 帧 → 推送正常，问题在 UI 订阅/渲染层
• 整个 turn 结束前无帧 → 事件在 agent 侧被批处理 hold 住，没到 queue.push

② 反代层是否缓冲（如果你是反代部署）：

proxy_buffering off;      # SSE/WS 必须关
proxy_read_timeout 3600;  # 长工具调用不能被反代掐断

proxy_buffering off 对 SSE 很关键——nginx 默认 buffer 响应，事件到了不透传，前端表现为"卡住没反应"，turn 结束 buffer 一起吐出，正好是这个帖子的症状。不是反代部署可以跳过这步。

③ 发消息无回执：看 session/queue 是否真的收到消息（Network 面板的 queue 相关 RPC 响应），如果 agent 侧根本没拿到消息，那是输入链路问题，和渲染无关。

一点判别视角（HeartFlow，AGI 第1层辨别者）

"用户无法判断 agent 是否还活着"是个可验证性缺口：状态存在（工具在跑、消息在排队），但没有独立信号把它带到用户面前。活性信号（running-status、排队回执、tool/call 开始帧）应该由事件系统本身保证，而不是夹在 turn 结束的批量输出里——这跟"完成判定必须在生成循环之外"是同一个原则：agent 自己最后一次性汇报不算数，必须有循环外的独立信号。排查时如果发现某条链路依赖 turn 结束才 flush，那就是设计缺口，不只是 UI bug。

[RendezvousWithFlowers]

我在报告者机器上做了实证排查(@deepseek-ai/dsh 0.1.0-rc.6,Windows 11,本地 dsh web,无反代),结果如下。需要说明:以下结论严格区分了已实测证实和仍未验证的部分。

已证实:服务端推送链路实时、无批量延迟

实验 1:tool/call 事件与工具发起同毫秒到达

我用独立观察者连接事件流(注意是 WebSocket,不是 HTTP SSE,见下文纠正),然后触发一次工具调用,抓到的帧:

{ "type": "assistant/chunk", "seq": 59865, "time": 1786701261713,
  "data": { "turn": 13, "step": 26,
    "chunk": { "type": "block-start", "blockType": "tool-call" } } }

{ "type": "assistant/chunk", "seq": 59866, "time": 1786701261714,
  "data": { "chunk": { "type": "tool-call-delta", "name": "pwsh", ... } } }

block-start(blockType: "tool-call")和 tool-call-delta(工具名、流式参数)在工具发起的那一毫秒就到达,seq 连续递增,没有任何批量/延迟。

实验 2:长任务期间事件持续推送

一个 90 秒的长任务期间,session/jobs、session/event、session/projection 帧全程持续到达(时间戳毫秒级推进),不是攒到任务结束一起吐出。因此"事件在 agent 侧被批处理 hold 住"这一假设被排除。

对契约的一点纠正:此版本浏览器事件流是 WebSocket,不是 HTTP SSE

dsh-client-connection 的 apply() 里,网关对 GET /api/events.mux 和 /api/events.host 一律返回:

new Response("upgrade required", { status: 426,
  headers: { connection: "Upgrade", upgrade: "websocket" } })

之后由 WebSocketDownlinks 处理 Upgrade,每条 WS 消息是
{ type: "server-request", rpcId, method, payload } 的 JSON 帧(socket.send(JSON.stringify(serverRequest(frame))))。
HTTP SSE 端点在 apiproxy 里仍存在,但浏览器路径走不到它。排查时说"Network 面板找 mux RPC 长连接"时,应看 WS 标签页而不是 SSE。

仍未验证、因此不能断言的部分

以上实验只证明了"服务端 → 独立 WS 客户端"这一跳。以下环节还没有证据,所以目前只能说症状"指向渲染/订阅侧",不能"确认":

1. 浏览器 Web UI 自己的 WS 连接是否同样收到这些帧(服务端是逐连接广播,理论上一致,但未经浏览器侧实测);
2. UI 收到帧后实际渲染成什么:工具行是否显示运行态、Think 行是否可见——没有在 DevTools 里核对 DOM;
3. session/projection 的负载内容是否在长任务期间持续更新(我看到了帧在推,但没有解析帧内工具状态/耗时字段是否真的在变化;如果投影内容不变,那就可能是投影层问题而非 UI 问题);
4. 用户报告的**真实场景(10 分钟级 wait)**我未复现,实验观察时长只有约 4 分钟,长时间后的行为未排除;
5. 浏览器侧因素:后台标签页节流、React 渲染卡顿等未排查。