d3vmeh/dsh-fetch-timeouts

Plugin插件 Native原生 ⭐ 3 MIT Dev Workflow开发与代码工作流

DeepSeek Harness plugin: raise Node's HTTP timeouts process-wide so slow local models (Ollama, LM Studio) are not cut off at 5 minutes

Project Overview项目介绍

This is a DeepSeek Harness plugin that globally raises Node.js HTTP request timeouts, preventing long-running model generation from being cut off. Use it for local models on Ollama or LM Studio that do not send keepalive pings. llama.cpp users usually do not need it, and dead connections take longer to detect after installation.

这是DeepSeek Harness的插件,用于全局提升Node.js的HTTP请求超时时间,避免模型生成长时间内容时被连接超时切断。在使用Ollama、LM Studio等不发送保活Ping的后端大模型时使用。llama.cpp服务器默认自带保活,一般无需该插件;延长超时后死连接需要更长时间才能被识别。

Or use CLI install (for developers)或使用命令行安装(适合开发者)

CLI Install命令行安装

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

d3vmeh/dsh-fetch-timeouts 加入你的 DSH 配置(web profile)即可启用。

READMEREADME

dsh-fetch-timeouts

Raises Node's HTTP timeouts for the whole DeepSeek Harness process, so a slow local model is not cut off after 5 minutes of silence.

The problem it fixes

Node's built-in fetch (which dsh's model adapters use) gives up when a server sends no response headers for 300 seconds, or no body bytes for 300 seconds. dsh has no setting for those two timers: streamIdleTimeoutMs is dsh's own watchdog and timeoutMs is the SDK's request timer, so raising them changes the failure message from pi-ai stream idle timeout to Failure reason: terminated (UND_ERR_BODY_TIMEOUT / UND_ERR_HEADERS_TIMEOUT) at exactly 5:00.

Servers that stay silent that long include Ollama and LM Studio while a model thinks or generates a large tool call (for example the entire contents of a file for write), and any backend that does not send keepalive pings. llama.cpp's llama-server sends a ping every 30 seconds by default, so llama.cpp users usually do not need this plugin.

Install

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

That is enough: the defaults raise both timeouts to 30 minutes. To change them, add to ~/.dsh/profiles/web/cordis.patch.yml:

- id: fetch-timeouts
  config:
    headersTimeoutMs: 3600000   # time allowed before response headers arrive; 0 disables
    bodyTimeoutMs: 3600000      # time allowed between body chunks; 0 disables

Restart dsh web. One line confirms it at startup:

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

Also raise dsh's own watchdog on the provider route, or it will fire first:

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

What you should know

  • It is process-wide. Every fetch that uses Node's global dispatcher (model calls, web search, HTTP MCP servers, cloud providers) gets the same longer limits; web_fetch is not affected because it builds its own per-request agent. A genuinely dead connection therefore takes up to the configured time to be noticed, and once you have raised streamIdleTimeoutMs as well, dsh's idle watchdog is the only remaining backstop for a hung model server. Reasonable on a single-user machine; think twice on a shared host.
  • It works by installing an undici Agent as Node's global fetch dispatcher. If NODE_USE_ENV_PROXY is set it installs undici's proxy-aware agent instead, so HTTP_PROXY, HTTPS_PROXY and NO_PROXY keep working. Tested on Node 22 with undici 8 (undici 8 requires Node 22.19 or newer). Confirmed by a user on Windows with Ollama on a 20 minute file write (discussion #4518).
  • Loading the plugin's undici dependency already swaps Node's default dispatcher for undici's own (same 300 second defaults); the plugin then applies your timeouts. undici only installs its default when no global dispatcher exists yet, so another plugin loading undici later cannot replace the plugin's agent. Unloading the plugin returns to undici's default, not to Node's original object.
  • It is a stopgap. When dsh exposes these timeouts itself (its pi-ai dependency already accepts a custom fetch), this plugin becomes unnecessary.

License

MIT

上一个 Prev deepseek-harness-yunoseek 下一个 Next dsh-bill