dsh web freezes (event loop blocked) after sending any message — Windows + Node 22

[15675110562]

Summary

After sending any message in the dsh web UI, the whole dsh web process becomes unresponsive: the port keeps listening but every HTTP request (including the page itself) times out. The process never recovers; it must be killed and restarted. This reproduces reliably on a fresh process with no third-party plugins.

Environment

• OS: Windows 11 (zh-CN), x64
• Node: v22.22.2
• dsh: 0.1.1-rc.2 (latest on npm, installed globally via npm i -g @deepseek-ai/dsh)
• Launch: dsh web (also reproduced with --no-open, --port 3081)
• Network: direct access to api.deepseek.com works fine (fetch to /chat/completions returns 200 in ~850 ms from the same machine)

Steps to reproduce

1. Run dsh web (server starts fine, UI loads, balance/usage widgets render normally).
2. While idle or browsing, the server is stable — 60/60 consecutive HTTP probes return 200.
3. Send any message (e.g. 1+1等于几？ / hello) in a session.
4. Within ~6 seconds the server stops answering: curl http://127.0.0.1:3080 times out. Port 3080 is still LISTENING.

Expected behavior

The model replies normally (streamed), like the one successful run observed: 你好，请回复OK两个字 → model answered OK in ~5 s (this single success happened while a Clash TUN proxy was active; the same request hangs when TUN is absent).

Actual behavior

• dsh web process stays alive (memory ~150–180 MB, no crash), but the event loop is blocked:
  • CPU usage is extremely low (0.1 s of CPU in an 8 s window → the process is waiting, not busy-looping).
  • No child processes are spawned/hanging (checked via WMI; the parent has no children).
  • Stdout/stderr are clean — no error logged.
• Every request to any bound port (3080, 3081) times out until the process is killed.
• Repro is independent of:
  • Plugins (reproduced with all plugins removed from the profile bundles),
  • Port (3080 and 3081 both),
  • Workspace directory (exists and is a local path),
  • Network (direct fetch to api.deepseek.com/chat/completions is 200 in <1 s).

Diagnostics collected

• dsh web uses streaming (stream: true) fetch via dsh-llm-deepseek (fetchImpl = globalThis.fetch) — the transport itself is fine (verified separately).
• The freeze happens after the message is submitted (server is healthy until then), i.e. somewhere in the agent-loop / tool-scheduling / session-persistence chain.
• Session persistence is JSONL + zstd (dsh-session-persistence-jsonl, uses node:zlib zstd APIs).
• dsh-subprocess-local / dsh-sandbox-local contain execSync / spawnSync / Atomics.wait usages; node-addon-landlock-run is also bundled (native module — npm i printed safe-delete cleanup warnings for its linux-arm64 variants on Windows).
• Watching the frozen process: 13 threads, no children, minimal CPU → strongly suggests a blocked synchronous wait or a native-module deadlock rather than a busy loop.

Suspected area

Freeze occurs after the first LLM turn completes (or while the agent loop starts its first tool-scheduling step). Candidates:

• Atomics.wait in dsh-subprocess-local/dsh-sandbox-local if a worker/subprocess never resolves;
• node-addon-landlock-run native module behavior on Windows;
• session persistence (zstd via node:zlib) during the first post-turn save.

Workaround

Kill the frozen dsh web process and restart. (I wrote a keep-alive watchdog that probes the port and auto-restarts on two consecutive failures.)

Additional notes

• The very first LLM call can succeed while a TUN-mode proxy (Clash) is running and deepseek.com traffic is routed through the proxy group; once the proxy is gone (system direct), every subsequent message freezes the process. This hint may matter for the scheduler/subprocess path.
• Please let me know if you need a process dump or logs; happy to run instrumented builds.

Thanks for looking into this — the tool is great, this bug makes it unusable on Windows at the moment.

[15675110562]

（以下为同一问题的中文版完整说明，方便中文用户阅读 / Chinese version of the same report）

dsh web 在发送任意消息后卡死（事件循环阻塞）——Windows + Node 22

摘要

在 dsh web 界面发送任意消息后，整个 dsh web 进程会失去响应：端口仍在监听，但所有 HTTP 请求（包括页面本身）都会超时。进程永远不会自行恢复，只能杀掉重启。在不安装任何第三方插件的全新进程上也能稳定复现。

环境

• 操作系统：Windows 11（简体中文版），x64
• Node：v22.22.2
• dsh：0.1.1-rc.2（npm 上的最新版，通过 npm i -g @deepseek-ai/dsh 全局安装）
• 启动方式：dsh web（也用 --no-open、--port 3081 复现过）
• 网络：本机直连 api.deepseek.com 完全正常（同一台机器上 fetch 调用 /chat/completions 约 850ms 返回 200）

复现步骤

1. 运行 dsh web（服务正常启动，界面正常加载，余额/用量组件正常显示）。
2. 空闲或浏览页面时服务稳定——连续 60 次 HTTP 探测全部返回 200。
3. 在会话中发送任意消息（例如 1+1等于几？ / hello）。
4. 约 6 秒内服务停止响应：curl http://127.0.0.1:3080 超时。端口 3080 仍然处于 LISTENING 状态。

预期行为

模型应正常（流式）回复，就像观察到的一次成功运行：你好，请回复OK两个字 → 模型约 5 秒回复 OK（唯一一次成功是在 Clash TUN 代理开启时；代理关闭后同样的请求就会挂起）。

实际行为

• dsh web 进程存活（内存约 150–180 MB，没有崩溃），但事件循环被阻塞：
  • CPU 占用极低（8 秒窗口内仅 0.1 秒 CPU → 进程处于等待状态，不是忙循环）。
  • 没有产生/挂起子进程（通过 WMI 检查；父进程没有子进程）。
  • stdout/stderr 干净——没有任何报错日志。
• 对任何端口（3080、3081）的所有请求都会超时，直到进程被杀死。
• 复现与以下因素无关：
  • 插件（从 profile bundles 中移除全部插件后仍可复现），
  • 端口（3080 和 3081 都一样），
  • 工作区目录（存在且为本地路径），
  • 网络（直连 api.deepseek.com/chat/completions 小于 1 秒返回 200）。

已收集的诊断信息

• dsh web 通过 dsh-llm-deepseek（fetchImpl = globalThis.fetch）使用流式（stream: true）fetch——传输层本身没问题（已单独验证）。
• 卡死发生在消息提交之后（此前服务一直健康），即 agent 循环 / 工具调度 / 会话持久化链路中的某处。
• 会话持久化是 JSONL + zstd（dsh-session-persistence-jsonl，使用 node:zlib 的 zstd API）。
• dsh-subprocess-local / dsh-sandbox-local 中包含 execSync / spawnSync / Atomics.wait 的使用；node-addon-landlock-run 也被打包（原生模块——npm i 在 Windows 上对其 linux-arm64 变体打印了 safe-delete 清理警告）。
• 观察卡死进程：13 个线程、无子进程、CPU 极低——强烈提示是同步等待被阻塞或原生模块死锁，而非忙循环。

疑似区域

卡死在第一个 LLM turn 完成之后（或 agent 循环开始第一次工具调度步骤时）。候选原因：

• dsh-subprocess-local / dsh-sandbox-local 中的 Atomics.wait——如果某个 worker/子进程永远不返回；
• node-addon-landlock-run 原生模块在 Windows 上的行为；
• 首次 turn 后的会话持久化（node:zlib 的 zstd）保存。

临时绕过方案

杀掉卡死的 dsh web 进程后重启。（我写了一个守护脚本，探测端口，连续两次失败即自动重启。）

补充说明

• 第一次 LLM 调用在 Clash TUN 模式代理运行且 deepseek.com 流量走代理分组时可以成功；代理一消失（系统直连），之后每条消息都会让进程卡死。这个线索可能对调度器/子进程路径有参考价值。
• 如果需要进程转储或日志，请联系我；很乐意配合运行插桩版本。

感谢关注——工具本身很好，但这个 bug 目前在 Windows 上让它的聊天功能完全不可用。

[denial123789]

The strongest next artifact would be three full process dumps taken while the HTTP probes are timing out, before the watchdog restarts the Host. The current observations prove a live-process availability failure, but they do not yet distinguish a stable main-thread wait from slow native progress.

I checked rc.2 commit b150a551b8d465e31e418e1b2eaf5e79bbb7d28e for the proposed candidates:

• production packages/ and apps/ contain no Atomics.wait() or execSync() call;
• production spawnSync() sites are limited to paths such as sandbox probes, plugin installation, and Windows process-tree termination;
• JSONL zstd append calls promisified node:zlib compression.

That does not clear any native frame, but it means package presence alone should not select the root cause. I would join port 3080 to the exact PID, record fixed-cadence HTTP probes, then capture three private full dumps five seconds apart:

$listener = Get-NetTCPConnection -LocalPort 3080 -State Listen -ErrorAction Stop
$dshPid = $listener.OwningProcess
New-Item -ItemType Directory -Force C:\dsh-hang-dumps | Out-Null
procdump64.exe -accepteula -ma -n 3 -s 5 $dshPid C:\dsh-hang-dumps

The same main-thread native frame across all three samples is much stronger evidence than one stack. If frames move, correlate each sample with the probe and provider timeline. ProcDump -h is not the right trigger here because it detects an unresponsive GUI window, which a headless Node Host may not own.

Please keep full dumps private: they can contain credentials, prompts, paths, environment values, and model output. A public follow-up can safely include only sanitized module/symbol/offset repetition and timing.

I turned the complete capture, WinDbg comparison, direct-vs-TUN A/B, recovery, and reporting sequence into an independent source-backed runbook: https://sandbaseai.github.io/deepseek-harness-handbook/windows-web-event-loop-hang.html