d3vmeh/dsh-fetch-timeouts

dsh-fetch-timeouts

为整个 DeepSeek Harness 进程提高 Node 的 HTTP 超时时间，这样慢速的本地模型就不会在静默 5 分钟后被切断。

它解决的问题

Node 内置的 fetch（dsh 的模型适配器所使用的）在服务器 300 秒内未发送响应头，或 300 秒内未发送任何响应体字节时会放弃。dsh 没有针对这两个计时器的设置：streamIdleTimeoutMs 是 dsh 自己的看门狗，timeoutMs 是 SDK 的请求计时器，因此提高它们只会把失败消息从 pi-ai stream idle timeout 变成 Failure reason: terminated（UND_ERR_BODY_TIMEOUT / UND_ERR_HEADERS_TIMEOUT），且恰好发生在 5:00。

会静默那么久的服务器包括 Ollama 和 LM Studio——当模型在思考或生成大型工具调用时（例如为 write 生成文件的全部内容），以及任何不发送 keepalive ping 的后端。llama.cpp 的 llama-server 默认每 30 秒发送一次 ping，所以 llama.cpp 用户通常不需要这个插件。

安装

dsh plugin --profile web add dsh-fetch-timeouts

这就足够了：默认值会将两个超时都提高到 30 分钟。要修改它们，请在 ~/.dsh/profiles/web/cordis.patch.yml 中添加：

- id: fetch-timeouts
config:
headersTimeoutMs: 3600000   # 响应头到达前允许的时间；0 表示禁用
bodyTimeoutMs: 3600000      # 响应体分块之间允许的时间；0 表示禁用

重启 dsh web。启动时会有一行日志确认：

fetch-timeouts: headers 1800000 ms, body 1800000 ms (process-wide)

同时也要提高 provider 路由上 dsh 自己的看门狗，否则它会先触发：

llm-pi-ai:
providers:
ollama:
streamIdleTimeoutMs: 1800000
timeoutMs: 1800000

你需要了解的

- 它是进程级的。每一个使用 Node 全局 dispatcher 的 fetch（模型调用、网络搜索、HTTP MCP 服务器、云提供商）都会获得同样更长的限制；web_fetch 不受影响，因为它会构建自己的每请求 agent。因此，一个真正死掉的连接最多需要配置的时间才会被察觉，而且一旦你也提高了 streamIdleTimeoutMs，dsh 的空闲看门狗就成了挂起的模型服务器仅剩的兜底。在单用户机器上合理；在共享主机上要三思。
- 它的工作原理是安装一个 undici Agent 作为 Node 的全局 fetch dispatcher。如果设置了 NODE_USE_ENV_PROXY，它会改为安装 undici 的代理感知 agent，这样 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY 会继续正常工作。已在 Node 22 和 undici 8 上测试（undici 8 需要 Node 22.19 或更新版本）。一位用户在 Windows 上使用 Ollama 进行 20 分钟的文件写入时已确认（discussion #4518）。
- 加载插件的 undici 依赖时，已经将 Node 的默认调度器替换为 undici 自带的调度器（同样是 300 秒的默认值）；随后插件会应用你的超时设置。undici 只会在尚不存在全局调度器时安装其默认调度器，因此之后加载 undici 的另一个插件无法替换该插件的 agent。卸载插件后会恢复到 undici 的默认值，而不是 Node 最初的对象。
- 这是一个临时方案。当 dsh 自身暴露这些超时设置时（其 pi-ai 依赖已经接受自定义 fetch），这个插件就不再需要了。

许可证

MIT