更新过后在内网环境下运行出现AbortSignal.any is not a function(internal) #3520

Frostlock-Z · 2026-08-20T04:17:01Z

Frostlock-Z
Aug 20, 2026

具体表现为在对话界面输入内容后发送会弹出AbortSignal.any is not a function(internal)报错
尝试过卸载重装node.js环境，清理npm缓存，重装dsh，使用npx启动
运行后自动弹出页面（记得初版不会）

运行方式dsh web和npx @deepseek-ai/dsh web

环境：
内网隔离环境，除npm和pip外无法访问互联网资源
系统为Windows 11 22H2 和 Windows 10
安全软件奇安信天擎，策略分发北信源
使用 npm install -g @deepseek-ai/dsh安装
安装时间为2026/08/20 10:55
node 版本v25.6.0
npm 版本11.9.0
pnpm 版本11.22.0
dsh --version显示0.1.0-rc.7

denial123789 · 2026-08-20T05:27:13Z

denial123789
Aug 20, 2026

The reported Node 25.6.0 detail is important contradictory evidence: rc.7 declares Node ^22.19.0 || >=24.0.0, and Node has exposed AbortSignal.any since 20.3.0 / 18.17.0. So this should not be handled as a generic "upgrade Node" case.

The first useful probe is to join the shell-visible version to the executable used by the running DSH Host:

where.exe node
node -p "JSON.stringify({execPath:process.execPath,version:process.version,any:typeof AbortSignal.any,timeout:typeof AbortSignal.timeout,execArgv:process.execArgv})"
Get-Command dsh | Format-List Source,Definition
"NODE_OPTIONS=$env:NODE_OPTIONS"
Get-CimInstance Win32_Process -Filter "Name = 'node.exe'" | Select-Object ProcessId,ParentProcessId,ExecutablePath,CommandLine | Format-List

We published a source-backed offline Windows runbook that routes old PATH runtime, alternate DSH process image, preload/wrapper/global modification, and damaged runtime distribution separately. It also avoids disabling endpoint security or applying a cancellation polyfill:

https://sandbaseai.github.io/deepseek-harness-handbook/abortsignal-any.html

Canonical source:
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/abortsignal-any-runtime-mismatch.md

If you can share the sanitized process.execPath, typeof AbortSignal.any, DSH node.exe image path, and NODE_OPTIONS, that should identify the owner without requiring internet access.

1 reply

Frostlock-Z Aug 20, 2026
Author

After investigation, it was found that the browser engine is Chromium 108.0.5359.95. When opening DevTools with F12 and executing console.log(typeof AbortSignal.timeout, typeof AbortSignal.any) in the console, the output is "function undefined". After changing to FireFox Nightly 132.0, no issues have been observed.

argszero · 2026-08-20T05:49:39Z

argszero
Aug 20, 2026

补充一个从报错指纹就能收窄根因的观察，配合 denial123789 的运行时身份排查：

1. 这个报错必然发生，不是偶发路径

AbortSignal.any 在这份代码里是核心设施——rc.8 全库 31 处调用（api/gateway、agent-loop、llm 全适配器、fetch 客户端、compaction、terminal、session-title、lsp、shell 持久工具、util/timeout……）。发送消息的热路径上至少有两处必然经过：

host/apiproxy/src/fetch/client.ts:313-316 postJson——C→S 双载体的共享 POST 腿（callUnary/respond 都走它），默认超时策略下只要有外部 signal 就 AbortSignal.any([AbortSignal.timeout(...), signal])
llm/llm-deepseek/src/adapter.ts:258（及 llm-pi-ai:302）——LLM 适配器同样合并

所以"每次对话发送都报错"不是某条可选路径坏了，而是只要运行时缺 AbortSignal.any，任何对话都无法进行——这与你的重装/清缓存无效完全自洽（动的是安装物，不是运行物）。

2. 报错指纹把环境收窄到一个版本区间

注意报错只说 AbortSignal.any 缺失、AbortSignal.timeout 没报——而这两个 API 的可用区间在 Node 里是错开的：

AbortSignal.timeout：Node 17.3.0+
AbortSignal.any：Node 20.3.0+ / 18.17.0+

浏览器端不存在"有 timeout 无 any"的组合（Chromium any=97 早于 timeout=103；Firefox 反之是 any 先有）。"timeout 在、any 不在"这个指纹只匹配 Node 17.3.x ~ 20.2.x（含 18.0–18.16）。也就是说：无论 shell 里 node -v 显示什么（你这里是 v25.6.0），实际运行 DSH 的那个 Node 一定落在 17.3–20.2 区间。

3. 两个离线可跑的判别命令

在出问题的机器上，不做任何安装改动：

# 确认启动 DSH 前的 Node 状态（正常应打印 true true v25.6.0）
node -e "console.log(typeof AbortSignal.timeout, typeof AbortSignal.any, process.version)"

# 绕过 UI 直接走纯 Node 热路径：如果这里也报错，就锁定在 Node 运行时层
dsh --headless "hi" --no-color 2>&1 | Select-Object -First 5

--headless 也报同样的错 → 运行时错配实锤，按 denial123789 的进程清单（Get-CimInstance Win32_Process ... ExecutablePath + where.exe node 全量输出）找出那个 17.3–20.2 的老 Node——内网企业环境里它常在别处：npm 全局 bin 目录残留、npx 缓存、企业分发的独立 Node 目录、安全软件 hook 出的沙箱 Node。卸载"重装 Node"改不到它，这解释了症状。
--headless 正常、只有 UI 对话报错 → 那才是渲染/UI 层问题，届时再单独看 Web 端。

4. 安全软件排除法（呼应 denial123789 的 global-modification 路径）：奇安信天擎/北信源在内网常做进程注入。若上面的命令显示 shell Node 完全正常、where.exe node 只有 v25.6.0、但 DSH 进程内的 process.version 却异常（用 runbook 里的 Win32_Process 查 ExecutablePath 后再 & $exe -p "process.version" 对比），那就是注入改写；否则先按版本错配找。