[Bug] "DeepSeek Messages transport failed" is a masked transport timeout — undici's 300 s bodyTimeout silently caps streamIdleTimeoutMs（传输层 300 秒上限被误报为传输失败）

[Matthew-Laplace]

Public / de-identified version. Machine paths, hostnames, local proxy ports and credentials have been
removed. Bilingual: English first, Chinese below (each section is self-contained).
Repro is fully offline — no provider account, no API key, no network egress.

• DSH Desktop 0.2.0-rc.2, macOS 26.6.2 (25G83), arm64, Bundle ID com.deepseek.dsh
• Packages: @deepseek-ai/dsh-llm-deepseek, @deepseek-ai/dsh-http-proxy, @deepseek-ai/dsh-llm, bundled undici@8.11.2
• Route: deepseek-account / deepseek-flash (same DeepSeekAdapter)
• Severity: medium — no data loss, but a configuration knob is silently inert above 300 000, and the
  failure is misclassified as a transport error, which sends users to the wrong layer (proxy / network / DNS)
• Reported: 2026-10-06 · Channel: GitHub Discussions (Issues are disabled on the official repo)

---

English

Summary

streamIdleTimeoutMs is documented as "Maximum provider idle time per outstanding stream read"
(dsh-llm-deepseek/README.md:62), and the same README states that stream-idle expiry throws TIMEOUT
(:118). Raising it above the default 300000 therefore looks like a supported way to tolerate a long
thinking pause.

It is not. The adapter issues a bare fetch() against the process-global undici dispatcher that DSH
installs at boot, and neither DSH's proxy-policy dispatcher nor the adapter overrides bodyTimeout /
headersTimeout. undici's default 300 s body timeout therefore fires first, and the resulting error
escapes the adapter's own TIMEOUT branch into the catch-all:

DeepSeek Messages transport failed          code = TRANSPORT
  cause: TypeError: terminated
    cause: BodyTimeoutError (UND_ERR_BODY_TIMEOUT): Body Timeout Error

So a timeout is reported as a transport failure, and streamIdleTimeoutMs > 300000 is an inert knob.

Symptom (observable criteria)

1. The turn fails with DeepSeek Messages transport failed, code = TRANSPORT, whose cause chain is
   LlmError → TypeError: terminated → BodyTimeoutError(UND_ERR_BODY_TIMEOUT).
2. The turn carries llm/retry / llm/retry-started events with failure.code = "TRANSPORT"
   (the default policy retries TRANSPORT up to 5 times).
3. The route is configured with streamIdleTimeoutMs > 300000.
4. Control: lower the same value below 300000 (e.g. 4000) and the identical silent stream reports
   DeepSeek Messages stream idle timeout with code = TIMEOUT. The watchdog path works; the transport
   timeout simply wins the race.

Deterministic reproduction (offline, no credentials, ~10 s)

A loopback SSE endpoint answers 200 + one message_start frame and then goes silent forever — no
socket reset, no error frame. The real DeepSeekAdapter from the shipped bundle is driven directly, so
nothing is stubbed except the provider.

# 1. extract the shipped modules from app.asar (no dependencies)
node extract-asar.mjs "/Applications/DeepSeek Harness.app/Contents/Resources/app.asar" /tmp/dsh-extract

# 2. watchdog-first vs transport-first on the same silent stream
node repro-min.mjs /tmp/dsh-extract            # ~10 s
node repro-min.mjs /tmp/dsh-extract --raw      # ~305 s: same case on undici's default bodyTimeout

repro-min.mjs (self-contained; extract-asar.mjs is a 30-line asar reader):

import http from 'node:http';
import path from 'node:path';
import { pathToFileURL } from 'node:url';

const EXTRACT = process.argv[2] ?? '/tmp/dsh-extract';
const RAW = process.argv.includes('--raw');
for (const n of ['HTTP_PROXY','HTTPS_PROXY','ALL_PROXY','http_proxy','https_proxy','all_proxy','NODE_USE_ENV_PROXY']) delete process.env[n];

const mod = (rel) => pathToFileURL(path.join(EXTRACT, 'dsh', 'node_modules', rel)).href;
const { DeepSeekAdapter, resolveAdapterOptions } = await import(mod('@deepseek-ai/dsh-llm-deepseek/lib/index.js'));
const undici = await import(mod('undici/index.js'));

const MESSAGE_START = {
  type: 'message_start',
  message: { id: 'msg_fixture', type: 'message', role: 'assistant', model: 'deepseek-flash',
             content: [], usage: { input_tokens: 7, output_tokens: 0 } },
};

async function fixture() {
  const server = http.createServer((_req, res) => {
    res.writeHead(200, { 'content-type': 'text/event-stream' });
    res.write(`event: message_start\ndata: ${JSON.stringify(MESSAGE_START)}\n\n`);
    // ...and then silence: a provider that stalled after the first frame.
  });
  server.requestTimeout = 0;      // do not race the client's own timeout
  server.headersTimeout = 0;
  server.keepAliveTimeout = 0;
  await new Promise((r) => server.listen(0, '127.0.0.1', r));
  return { server, port: server.address().port };
}

async function run({ streamIdleTimeoutMs, bodyTimeoutMs }) {
  const { server, port } = await fixture();
  const connection = resolveAdapterOptions({ baseURL: `http://127.0.0.1:${port}`, streamIdleTimeoutMs }, undefined);
  const adapter = new DeepSeekAdapter({
    options: () => connection,
    resolveAuth: async () => ({ headers: { authorization: 'Bearer fixture-key' } }),
    resolveUserId: () => 'fixture',
    resolveFiles: () => ({}),
    prepareExtensions: async () => ({ fields: {}, accept: async () => {} }),
  });
  let restore;
  if (bodyTimeoutMs !== undefined) {                       // stand-in for the dispatcher DSH installs
    const agent = new undici.Agent({ bodyTimeout: bodyTimeoutMs, headersTimeout: bodyTimeoutMs });
    undici.setGlobalDispatcher(agent);
    restore = () => undici.setGlobalDispatcher(new undici.Agent());
  }
  const t0 = Date.now();
  let out;
  try {
    for await (const _ of adapter.stream({ provider: 'deepseek', model: 'deepseek-flash',
      messages: [{ role: 'user', content: [{ type: 'text', text: 'ping' }] }] })) { /* drain */ }
    out = { code: 'OK' };
  } catch (error) {
    const chain = [];
    for (let e = error; e; e = e.cause) chain.push(`${e.name}${e.code ? `(${e.code})` : ''}: ${e.message}`);
    out = { code: error.code, message: error.message, chain };
  }
  restore?.();
  server.closeAllConnections?.();
  await new Promise((r) => server.close(r));
  return { ms: Date.now() - t0, ...out };
}

console.log('watchdog first   (streamIdleTimeoutMs=4000):', JSON.stringify(await run({ streamIdleTimeoutMs: 4000 }), null, 2));
console.log(`transport first  (streamIdleTimeoutMs=900000, bodyTimeout=${RAW ? 'undici default' : '6000'}):`,
  JSON.stringify(await run({ streamIdleTimeoutMs: 900000, bodyTimeoutMs: RAW ? undefined : 6000 }), null, 2));

Actual output (2026-10-06):

watchdog first   (streamIdleTimeoutMs=4000): {
  "ms": 4020,
  "code": "TIMEOUT",
  "message": "DeepSeek Messages stream idle timeout",
  "chain": [
    "LlmError(TIMEOUT): DeepSeek Messages stream idle timeout",
    "TimeoutReason(MESSAGES_IDLE): MESSAGES_IDLE after 4000ms"
  ]
}
transport first  (streamIdleTimeoutMs=900000, bodyTimeout=6000): {
  "ms": 6515,
  "code": "TRANSPORT",
  "message": "DeepSeek Messages transport failed",
  "chain": [
    "LlmError(TRANSPORT): DeepSeek Messages transport failed",
    "TypeError: terminated",
    "BodyTimeoutError(UND_ERR_BODY_TIMEOUT): Body Timeout Error"
  ]
}

With --raw (undici defaults, nothing shortened) the second run fails after 301 518 ms with the same
TRANSPORT / BodyTimeoutError pair, while streamIdleTimeoutMs is 900000.

Scenario matrix from the fuller harness (each row = a different provider behaviour; same driver):

#	provider behaviour	streamIdleTimeoutMs	transport timeout	observed
S2	200 + message_start, then silence	900000	body 6 s (shortened)	TRANSPORT → BodyTimeoutError
S1	same	900000	undici default	identical, 301 518 ms
S3	same	4000	default	TIMEOUT stream idle timeout (MESSAGES_IDLE after 4000ms)
S4	HTTP 500 + JSON error	900000	default	SERVER
S5	in-band SSE error frame (rate_limit_error)	900000	default	RATE_LIMIT
S6	complete valid stream	900000	default	success (5 events)
S7	socket.destroy() after the first frame	900000	default	TRANSPORT (SocketError UND_ERR_SOCKET) — the legitimate use of this code
S8	caller abort	900000	default	ABORTED

S4/S5/S7/S8 are controls: TRANSPORT should mean a socket-level failure. A timeout is not one.

Expected vs Actual

Expected	streamIdleTimeoutMs is the maximum provider idle time per outstanding stream read; idle expiry throws TIMEOUT; TRANSPORT covers pre-response transport failures only (README.md:62, :118). Setting 900000 tolerates a 15-minute silent stream.
Actual	undici's fixed 300 s body timeout fires first; the failure is reported as TRANSPORT; TIMEOUT never sees it; streamIdleTimeoutMs above 300000 has no effect.

Evidence (code chain)

1. The adapter has a TIMEOUT branch — dsh-llm-deepseek/lib/index.js:2129-2132:

} catch (error) {
    if (timeoutOf(watchdog.signal, "MESSAGES_IDLE") !== void 0) throw new LlmError("DeepSeek Messages stream idle timeout", "TIMEOUT", { cause: error });
    if (options.signal?.aborted) throw new LlmError("DeepSeek Messages request aborted", "ABORTED", { cause: error });
    if (error instanceof LlmError) throw error;
    throw new LlmError("DeepSeek Messages transport failed", "TRANSPORT", { cause: error });
}

2. The watchdog is armed with the configured value (:2118), default 300000 (:17), and only recognises its
   own TimeoutReason("MESSAGES_IDLE"). Any other timeout falls through.

3. The request is a bare fetch() with no dispatcher (:2188); the body is consumed by parseSse at :2221.
   Transport timeouts are therefore owned by the process-global dispatcher.

4. That dispatcher is installed by DSH at boot: dsh/lib/profile-boot-*.js:225 →
   installProxyFromEnvironment() (dsh-http-proxy/lib/index.js:519) → installGlobalProxy() (:415) →
   createPolicyDispatcher() (:388-397):

return new Agent({ factory(origin, options) {
    const passed = options;
    const proxy = proxyForUrl(policy, new URL(origin.toString()));
    if (proxy !== void 0) return new ProxyAgent({ ...passed, uri: proxy });
    return new Pool(origin, passed);
} });

No bodyTimeout / headersTimeout / connectTimeout override anywhere, so undici's Client defaults apply:
bodyTimeout = headersTimeout = 300e3 (undici/lib/dispatcher/client.js:316-317), connect (including proxy
tunnel) 10e3 (undici/lib/core/connect.js:69).

5. TRANSPORT is in the default retryable set — dsh-llm/lib/types/retry-policy.js:12-21
   (maxRetries = 5, backoff 500 ms → 10 s).

Impact

1. Inert configuration: streamIdleTimeoutMs > 300000 does nothing.
2. Misclassification → guaranteed misdiagnosis: a timeout is labelled a transport failure, contradicting the
   README and pointing users at proxies, DNS, TLS and VPNs. This is the real cost: the reporter's first
   hypothesis was the local proxy chain, and only an offline reproduction showed the label was wrong.
3. Retry amplification: since the failure is TRANSPORT, up to 5 retries follow, each with its own 300 s
   transport cap — a single stalled stream can hold a turn for roughly 30 minutes before the error reaches
   the user, while the configured 15-minute patience is neither honoured nor visible.
4. Shared dispatcher: every provider that issues fetch() inherits the 300 s body cap. Whether it surfaces
   as TRANSPORT depends on each provider's own catch classification (worth auditing for the other adapters).

Root cause

Confirmed (code + offline reproduction)

• The adapter does not control transport timeouts, and the process-global dispatcher does not lower/raise them,
  so the 300 s cap is decoupled from streamIdleTimeoutMs.
• BodyTimeoutError reaches generate()'s catch as TypeError: terminated and lands in the catch-all → TRANSPORT.
• The TIMEOUT branch itself works (S3) — it simply never wins the race.
• The reproduction needs no network, no proxy and no credentials.

Inferred (no live capture yet)

• Whether real sessions have already failed this way is not confirmed. The trigger is a >300 s byte gap in
  the SSE stream; DeepSeek sends SSE comment heartbeats (the adapter renews its watchdog via onComment), so a
  healthy stream never triggers it. A scan of every persisted session transcript on the reporting machine found
  no TRANSPORT / llm/retry records. The defect does not depend on that: any 5-minute silence necessarily
  produces the misleading error.
• The ~30-minute figure for the retry amplification is arithmetic (6 attempts × 300 s), not an end-to-end measurement.

Suggested fix

A. Make the transport timeout follow the configuration (preferred):

const dispatcher = new Agent({
  bodyTimeout: connection.streamIdleTimeoutMs,          // let the TIMEOUT branch own this deadline
  headersTimeout: Math.min(connection.streamIdleTimeoutMs, 60_000),
});
const response = await fetch(url, { method: 'POST', signal, dispatcher, /* ... */ });

If traffic must go through DSH's own proxy policy, the parameter has to reach ProxyAgent / Pool as well
(createPolicyDispatcher currently forwards passed unchanged, with no timeout fields).

B. Fix the classification (independent of A, both recommended): map transport-layer timeouts to TIMEOUT:

const TRANSPORT_TIMEOUT_CODES = new Set(['UND_ERR_BODY_TIMEOUT', 'UND_ERR_HEADERS_TIMEOUT', 'UND_ERR_CONNECT_TIMEOUT']);
for (let e = error; e; e = e.cause) {
  if (TRANSPORT_TIMEOUT_CODES.has(e.code)) throw new LlmError('DeepSeek Messages transport timeout', 'TIMEOUT', { cause: error });
}

Only then does README.md:118 hold, and users stop debugging their proxies.

C. Fallback if A/B are deferred: clamp streamIdleTimeoutMs at validation time to the effective transport
ceiling (≤ 300 000) with an explicit warning, so a value that cannot work is not silently accepted.

---

中文

摘要

streamIdleTimeoutMs 的文档定义是"每次未完成流读取的最大 provider 空闲时间"
（dsh-llm-deepseek/README.md:62），同一份 README 还写明"流空闲到期抛 TIMEOUT"（:118）。
因此把默认的 300000 调大，看起来是"容忍长时间思考停顿"的受支持做法。

事实并非如此。适配器用的是不带 dispatcher 的裸 fetch()，走的是 DSH 启动时装的进程级 undici dispatcher；
DSH 自己的代理策略 dispatcher 与适配器都没有覆写 bodyTimeout / headersTimeout。于是 undici 默认的
300 秒 body timeout 先触发，而这个错误没有进入适配器自己的 TIMEOUT 分支，而是落进 catch-all：

DeepSeek Messages transport failed          code = TRANSPORT
  cause: TypeError: terminated
    cause: BodyTimeoutError (UND_ERR_BODY_TIMEOUT): Body Timeout Error

即：超时被报成传输失败，并且 streamIdleTimeoutMs > 300000 是一个失效的旋钮。

现象（可观测判据）

1. 该轮失败信息为 DeepSeek Messages transport failed，code = TRANSPORT，
   cause 链为 LlmError → TypeError: terminated → BodyTimeoutError(UND_ERR_BODY_TIMEOUT)。
2. 该轮出现 llm/retry / llm/retry-started 事件且 failure.code = "TRANSPORT"（默认策略会重试 5 次）。
3. 该路由配置了 streamIdleTimeoutMs > 300000。
4. 反证：把同一个值降到 300000 以下（例如 4000），面对完全相同的静默流会报
   DeepSeek Messages stream idle timeout（code = TIMEOUT）。看门狗那条路径本身是好的，
   只是被传输层超时抢了先。

确定性复现（离线、无需凭据，约 10 秒）

一个 loopback SSE 端点返回 200 + 一帧 message_start 后永久静默——不是断链，也不是错误帧。
驱动的是打包里的真 DeepSeekAdapter，除了 provider 之外没有任何桩。

# 1) 从 app.asar 解出随包发布的模块（无第三方依赖）
node extract-asar.mjs "/Applications/DeepSeek Harness.app/Contents/Resources/app.asar" /tmp/dsh-extract

# 2) 同一条静默流上，看门狗先到 vs 传输超时先到
node repro-min.mjs /tmp/dsh-extract            # 约 10 秒
node repro-min.mjs /tmp/dsh-extract --raw      # 约 305 秒：用 undici 默认 bodyTimeout 原样复现

repro-min.mjs 全文见英文部分的代码块（自包含；extract-asar.mjs 是一个约 30 行的 asar 读取器）。
实际输出（2026-10-06）：

watchdog first   (streamIdleTimeoutMs=4000): {
  "ms": 4020,
  "code": "TIMEOUT",
  "message": "DeepSeek Messages stream idle timeout",
  "chain": [
    "LlmError(TIMEOUT): DeepSeek Messages stream idle timeout",
    "TimeoutReason(MESSAGES_IDLE): MESSAGES_IDLE after 4000ms"
  ]
}
transport first  (streamIdleTimeoutMs=900000, bodyTimeout=6000): {
  "ms": 6515,
  "code": "TRANSPORT",
  "message": "DeepSeek Messages transport failed",
  "chain": [
    "LlmError(TRANSPORT): DeepSeek Messages transport failed",
    "TypeError: terminated",
    "BodyTimeoutError(UND_ERR_BODY_TIMEOUT): Body Timeout Error"
  ]
}

加 --raw（完全用 undici 默认值，不做任何缩短）时，第二条在 301 518 ms 后失败，错误对完全相同，
而此时 streamIdleTimeoutMs 是 900000。

更完整的对照矩阵（同一驱动，只改 provider 行为）：

#	假 provider 行为	streamIdleTimeoutMs	传输超时	观测
S2	200 + message_start 后静默	900000	body 6 秒（缩短以便确定复现）	TRANSPORT → BodyTimeoutError
S1	同上	900000	undici 默认	同上，301 518 ms
S3	同上	4000	默认	TIMEOUT stream idle timeout（MESSAGES_IDLE after 4000ms）
S4	HTTP 500 + JSON error	900000	默认	SERVER
S5	带内 SSE error 帧（rate_limit_error）	900000	默认	RATE_LIMIT
S6	完整合法流	900000	默认	成功（5 个事件）
S7	首帧后 socket.destroy()	900000	默认	TRANSPORT（SocketError UND_ERR_SOCKET）——这才是该 code 的正当用法
S8	调用方 abort	900000	默认	ABORTED

S4/S5/S7/S8 是对照组：TRANSPORT 应当只表示 socket 级失败，而超时不是。

期望 vs 实际

期望	streamIdleTimeoutMs 是每次未完成流读取的最大 provider 空闲时间；空闲到期抛 TIMEOUT；TRANSPORT 只覆盖响应前的传输失败（README.md:62、:118）。设成 900000 就应容忍 15 分钟静默。
实际	undici 固定的 300 秒 body timeout 先触发，失败被归为 TRANSPORT；TIMEOUT 分支永远看不到它；streamIdleTimeoutMs 在 300000 以上不产生任何效果。

证据（代码链）

1. 适配器自己就有 TIMEOUT 分支 —— dsh-llm-deepseek/lib/index.js:2129-2132（代码见英文部分）。
2. 看门狗用配置值装配（:2118），默认 300000（:17），且只认自己的
   TimeoutReason("MESSAGES_IDLE")，任何别的超时都掉出去。
3. 请求是不带 dispatcher 的裸 fetch()（:2188），响应体在 :2221 进入 parseSse。
   因此传输层超时由进程级 dispatcher 决定。
4. 该 dispatcher 由 DSH 在启动时安装：dsh/lib/profile-boot-*.js:225 →
   installProxyFromEnvironment()（dsh-http-proxy/lib/index.js:519）→ installGlobalProxy()（:415）→
   createPolicyDispatcher()（:388-397，代码见英文部分）。没有任何超时覆写，
   于是 undici 的 Client 默认值生效：bodyTimeout = headersTimeout = 300e3
   （undici/lib/dispatcher/client.js:316-317）、建连（含代理隧道）10e3（undici/lib/core/connect.js:69）。
5. TRANSPORT 在默认可重试集合内 —— dsh-llm/lib/types/retry-policy.js:12-21（maxRetries = 5，退避 500 ms → 10 s）。

影响面

1. 配置静默失效：streamIdleTimeoutMs > 300000 完全不起作用。
2. 分类错误 → 必然误诊：超时被贴上"传输失败"标签，与 README 的契约相反，把排查引向代理、DNS、TLS、VPN。
   这才是真正的成本：报告者的第一反应就是本地代理链，只有离线复现才证明标签是错的。
3. 重试放大：因为分类是 TRANSPORT，最多还会重试 5 次，每次尝试各自受 300 秒传输上限约束——
   一次"停滞型"故障最坏可以把一轮卡住约 30 分钟才把错误交给用户；而配置里那 15 分钟容忍度既没被尊重、也不可见。
4. 共用 dispatcher：所有走 fetch() 的 provider 都继承这个 300 秒 body 上限；是否显示为 TRANSPORT
   取决于各 provider 自己的 catch 分类（其他适配器值得单独核查）。

根因判断

确认（代码 + 离线复现）

• 适配器不控制传输层超时，进程级 dispatcher 也不抬高/降低它，于是 300 秒上限与 streamIdleTimeoutMs 解耦。
• BodyTimeoutError 以 TypeError: terminated 的形式到达 generate() 的 catch，落进 catch-all → TRANSPORT。
• TIMEOUT 分支本身是好的（S3），只是抢不到。
• 复现不需要网络、代理或凭据。

推断（尚无线上直接证据）

• 线上是否已经这样失败过：未确认。触发条件是 SSE 出现 >300 秒的无字节间隔；DeepSeek 会发 SSE comment
  心跳（适配器用 onComment 给看门狗续期），心跳正常时不会触发。对报告机器的全部已持久化会话记录扫描后
  未发现 TRANSPORT / llm/retry 记录。缺陷不依赖这一点：只要出现 5 分钟静默，这条误导性报错必然出现。
• 影响 3 中"约 30 分钟"是算术推演（6 次尝试 × 300 秒），不是端到端计时。

建议修复

A. 让传输层超时服从配置（首选）：请求处挂显式 dispatcher，用 streamIdleTimeoutMs 作为 body 上限
（headersTimeout 另设一个合理的小值）；若流量必须走 DSH 自己的代理策略，该参数需要一路传到
ProxyAgent / Pool（createPolicyDispatcher 现在把 passed 原样透传，没有超时字段）。

B. 修正分类（与 A 独立，建议同时做）：把传输层超时映射为 TIMEOUT
（UND_ERR_BODY_TIMEOUT / UND_ERR_HEADERS_TIMEOUT / UND_ERR_CONNECT_TIMEOUT，沿 cause 链判断）。
代码见英文部分。只有这样才能让 README.md:118 的契约成立，用户也不会再去查代理。

C. 兜底（A/B 短期不做时）：在校验层把 streamIdleTimeoutMs 钳制到有效上限（≤ 300 000）并显式告警，
避免"能填但无效"的配置。

[PerryLink]

你的机制与两处默认值恰好撞在一起——我把这条数字对齐核到了

1. 关键巧合：两个 300 秒

我核到本仓自己的流空闲超时默认值就是 300 秒（当前 HEAD = 0.2.1-alpha.1）：

packages/llm/llm-deepseek/src/defaults.ts:4   export const DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000
packages/llm/llm-pi-ai/src/config.ts:47       export const DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000

而 undici 的 bodyTimeout 默认值也是 300 秒。⇒ 两个 300 秒撞在同一处，于是表现为"恰好在那条边界上被报成 DeepSeek Messages transport failed"。你"300 s 上限被误报为传输失败"这个读法在数字上完全吻合。

2. 但我要如实说一处证据边界

我在 packages/util/http-proxy/src 与 packages/llm 里检索 bodyTimeout / headersTimeout，没有命中。⇒ 也就是说：那个 300 秒上限不是本仓设置的，而是 undici 自带的默认。

这对修法影响很大，建议在报告里点明：

本仓未显式设置 bodyTimeout，因此该上限来自 undici 默认值；要修就需要显式配置 dispatcher（把它调到 ≥ streamIdleTimeoutMs，或让两者由同一配置驱动），否则"我方超时"与"库超时"会继续各自为政。

这一段能让你的报告从"现象描述"变成"可执行的修法方向"。

3. 关于"误报"这一层（与你的标题一致）

错误文案 DeepSeek Messages transport failed 是兜底包装：packages/llm/llm-deepseek/src/adapter.ts:66 会把请求阶段的非 LlmError 一律包成 TRANSPORT 并保留 cause。⇒ 因此真实原因（超时）并没有丢，只是没被呈现。建议把诉求写成两条：

1. 对齐两处超时（或显式配置 undici 的 bodyTimeout）；
2. 错误文案带出 cause（或对"我方空闲超时"用一个独立码），使"网络失败"与"超时"可区分。

4. 你那条"完全离线可复现"很有价值

（无需账号/密钥/外网）——这会让维护者能直接跑。请保留。

5. 版本提醒（本轮基线已变，请以此为准）

HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1
npm: latest = 0.2.0-rc.2    next = 0.2.0-rc.2    alpha = 0.2.1-alpha.1

⚠️ 注意：npm 的 latest 已经不再是旧的 0.1.5-rc.3（那是几周前的情况）。你在 Desktop 0.2.0-rc.2 上复现 ⇒ 属当前发布线，无需升级即可提。

一条边界

我确认的是两处 300 000 ms 默认值的存在与位置、本仓源码里没有 bodyTimeout 设置、以及兜底包装保留 cause。你那条离线复现的实测数据以你为准——我没有跑它。

[Matthew-Laplace]

Confirmed and folded into the report / 已确认并写入报告

Thanks. Both points are accepted and folded into the report, public and internal versions.

What changed on my side:

1. Source of the 300 s cap. The repository's own defaults are 300_000 at packages/llm/llm-deepseek/src/defaults.ts:4 and packages/llm/llm-pi-ai/src/config.ts:47. The repository does not set bodyTimeout or headersTimeout (no hits under packages/util/http-proxy/src or packages/llm). The effective cap is undici's default.
2. Fix direction. The dispatcher must set the timeout explicitly. Set bodyTimeout >= streamIdleTimeoutMs, or drive both deadlines from one configuration source.
3. Two asks. First, align the two timeouts. Second, surface cause or use a distinct code for our own idle timeout, so transport failure and timeout are distinguishable.
4. Version baseline. HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1; npm latest = 0.2.0-rc.2, next = 0.2.0-rc.2, alpha = 0.2.1-alpha.1. The reproduction on Desktop 0.2.0-rc.2 is still on the current release line, so no upgrade is needed for this report.
5. Offline reproduction. It is kept unchanged. I recorded your note that its value is in being directly runnable.

---

谢谢确认。两点都已折进报告（公开版与内部版）。

我这边改了这些：

1. 300 秒上限的来源：仓库自身默认值也是 300_000，位置为 packages/llm/llm-deepseek/src/defaults.ts:4 与 packages/llm/llm-pi-ai/src/config.ts:47。仓库没有显式设置 bodyTimeout / headersTimeout（在 packages/util/http-proxy/src 与 packages/llm 检索无命中），生效上限来自 undici 默认值。
2. 修法方向：必须显式配置 dispatcher。把 bodyTimeout 调到 >= streamIdleTimeoutMs，或让两者由同一配置驱动。
3. 两条诉求：① 对齐两处超时；② 错误文案带出 cause，或给“我方空闲超时”独立错误码，让“传输失败”与“超时”可区分。
4. 版本基线：HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1；npm latest = 0.2.0-rc.2，next = 0.2.0-rc.2，alpha = 0.2.1-alpha.1。在 Desktop 0.2.0-rc.2 上的复现仍属当前发布线，报告无需升级。
5. 完全离线复现保留不变；你认可它的价值这一点我已记入报告。

[kakatata]

如果你的电脑同时拥有卡巴斯基和DSH，出现"DeepSeek Messages transport failed"有可能是因为卡巴斯基的https中间人检查导致的，在卡巴斯基中将api.deepseek.com放入受信任的地址中即可解决这个问题