dsh-fetch-timeouts
提高整个 DeepSeek Harness 进程的 Node HTTP 超时时间，避免运行缓慢的本地模型在 5 分钟时被中断
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:d3vmeh/dsh-fetch-timeouts#2b4e09b350e93bb2b61d0c4a25f5bb5bbaa60a68Fetch Timeouts 以 dsh-fetch-timeouts 发布，当前版本为 0.1.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
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.
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.
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
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.HTTP_PROXY, HTTPS_PROXY and NO_PROXY keeps working. If NODE_USE_ENV_PROXY is set, the plugin uses undici's proxy-aware agent instead, as it did in 0.1.0. On dsh 0.2 you do not need that variable, and setting it swaps dsh's proxy rules for undici's, which differ slightly (for example on loopback addresses other than 127.0.0.1). 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).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 wrapper. Unloading the plugin puts back the dispatcher it wrapped.fetch), this plugin becomes unnecessary.MIT