[≤0.1.7-rc.1] session-log-deepseek 默认被开启（0.1.6-alpha.1 起）：请求体无上限 → 413 永久自锁，现场报 TRANSPORT 超时（复现 + 实测阈值；rc.2 已修 #5168）

[temotee2103]

与已有讨论的关系：本贴是 #7658（同一根因的主帖）的补充，不是重复贴 —— #7736 曾因重复被撤回，因此这里只补充原帖没有的 4 条新事实：

1. @deepseek-ai/dsh-session-log-deepseek 的 enabled 默认值被翻成 true，起点是 dsh-v0.1.6-alpha.1（commit 31ec6bc7e3，2026-09-14），不是 0.1.7-rc.1（本机 lib/index.js:16 实测；版本定位由社区 @argszero 用 git tag --contains 31ec6bc7e3 给出）—— 0.1.6-alpha.1 及以后都受影响，这解释了近期为何"突然大面积"出现；
2. 现场为何表现为 TRANSPORT 而不是干净的 413（本条已按 @argszero 的源码复核修正）：干净 413 → INVALID_REQUEST，不在重试白名单、不会被重试；而 TRANSPORT 是"任何非 LlmError"的兜底（adapter.ts:47），且在重试白名单内（retry-policy.ts:17-23，最多 5 次）—— 每次重试都会重新 prepare 并重传整个字段（48 MB × 5 ≈ 240 MB/轮），正好解释我们记录的 53 分钟里 35 次 turn/end。真正的产生者是超过 V8 字符串上限导致的 JSON.stringify RangeError（上游修复决策记录），而不是空闲看门狗（看门狗触发的是 TIMEOUT，默认 5 分钟，与实测 22.7 秒差一个数量级）；用 error.cause 可判别；
3. workaround 必须打在 home 层（$DSH_HOME/cordis.patch.yml）才能覆盖 tui / headless，只改 profiles/web/cordis.patch.yml 盖不住；
4. 小会话（132 / 58 事件，字段≈0 MB）同样报 TRANSPORT —— @argszero 指出 llm-deepseek 有两个 TRANSPORT 产点：adapter.ts:47（Messages）与 files-api.ts:160（Files API，会话带图片附件时走这条），用 error.cause + 会话是否含附件即可区分；小会话（几 KB）不可能是水位自锁。

---

关联讨论：#7736、#7658
环境：Windows，DSH 0.1.7-rc.1，@deepseek-ai/dsh-session-log-deepseek@0.1.7-rc.1

TL;DR

更新（2026-09-25）：本问题已在上游 dsh-v0.1.7-rc.2 修复 —— commit 193f9ce413（PR #5168）新增 session-log-deepseek.Config.maxBytes（默认 8 MiB）：每次只发"水位之后最长的可容纳前缀"并推进水位，单个事件超限则省略字段并 warn，合并体不可序列化时降级为 base body。因此本贴的 enabled: false 只适用于 ≤ 0.1.7-rc.1，rc.2+ 无需关闭该插件（复核信息由社区 @argszero 在评论中给出）。

enabled 默认值被翻成 true 的起点是 dsh-v0.1.6-alpha.1（commit 31ec6bc7e3，2026-09-14），不是 0.1.7-rc.1。
该插件会把整份会话日志当作顶层字段 dsh_session_log 塞进 每一次 Messages 请求，且 fail-closed + 无体积上限。
一旦「接受水位」失效，afterSeq 回退为 -1，于是每次请求都重发整份日志（本机实测最大 97.4 MB），
被端点以 HTTP 413 拒绝；413 又不重试、不写水位 —— 形成永久自锁。

修复（home 层，对所有 profile 生效）：

# $DSH_HOME/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

---

1. 现象

• 会话「一直请求超时」，Web UI 长时间无响应后报错。
• 日志中反复出现：

turn/end   code = TRANSPORT
"DeepSeek Messages transport failed"          code = TRANSPORT
"DeepSeek API request to https://api.deepseek.com failed"   code = TRANSPORT

• 故障时间集中在 2026-09-24 19:40–20:33（UTC+8），共 35 次 turn/end TRANSPORT。
• 重试策略本身是正常的，但白名单里没有 INVALID_REQUEST：

policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]

2. 定位过程

2.1 先排除网络

api.deepseek.com → CNAME d3bbv8sr76az5s.cloudfront.net → 正常解析；TCP 443 可达；WinHTTP 无代理。网络不是原因。

2.2 会话日志里的关键证据

两个大会话的接受水位为 0（即从未成功交付过），重算出的 dsh_session_log 字段体积：

会话	事件数	水位	重算字段体积
3604e97a…	41624	0	97.4 MB
009a6a36…	41569	0	97.3 MB

2.3 读插件源码，确认机制（dsh-session-log-deepseek/lib/index.js）

// L16   默认开启（0.1.5-rc.2 之前是 false）
const Config = z.object({ enabled: z.boolean().default(true) });

// L96   版本作用域：格式迁移后旧水位全部作废
if (acceptedFormatVersion !== session.header.version) continue;

// L119  关闭时直接不注册字段
if (config.enabled !== true) return;

// L127  afterSeq = -1 时 → snapshotEvents(0) → 整份日志
const suffix = session.snapshotEvents(SessionLogOffset(afterSeq + 1));

水位 只在 HTTP 2xx 之后的 accept() 里写入。README 也明确写着：

No independent request-size cap —— complete delivery is fail-closed; provider rejection leaves the cursor unchanged instead of truncating the log.

即：失败 → 不写水位 → 下次重发更大 → 更容易失败，这是一条只能向坏的方向走的死循环。

2.4 实测端点体积阈值（决定性证据）

用同一把 key 向同一端点 https://api.deepseek.com/anthropic/v1/messages 发送分级大小的请求体（携带一个 dsh_session_log 占位字段）：

请求体	结果	耗时
0 MB（对照）	HTTP 200	886 ms
8 MB	HTTP 200	3628 ms
48 MB	HTTP 413 Failed to buffer the request body: length limit exceeded	22708 ms
96 MB	HTTP 413（openresty）	843 ms

阈值落在 8 MB 与 48 MB 之间。

2.5 为什么表现为「TRANSPORT」而不是「413 报错」（已修正）

dsh-llm-deepseek 里状态码映射是：

• L1500：status === 400 || status === 413 → INVALID_REQUEST（不在重试白名单 → 不重试、不写水位）；
• adapter.ts:47：任何非 LlmError 的异常 → TRANSPORT（在重试白名单内：retry-policy.ts:17-23，DEFAULT_MAX_RETRIES = 5）。

修正：原稿把原因归给"上传过慢逼近空闲看门狗"，这一条已按 @argszero 的源码复核撤回 —— 看门狗（adapter.ts:54）触发的是 TIMEOUT（:44），不可能变成 TRANSPORT；且 DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000（5 分钟）与实测 22.7 秒差一个数量级。上游修复的决策记录给出的真正原因是：日志超过 V8 字符串上限时，合并后的 JSON.stringify 抛 RangeError，适配器将其当作非 LlmError 报成 TRANSPORT；默认重试策略会重复同一次序列化，于是永远到不了 2xx、水位永不推进。

额外后果：因为 TRANSPORT 会被重试最多 5 次，每轮都重新 prepare 并重传整个字段 —— 48 MB 的请求体一轮最多可上传约 240 MB，与 53 分钟内 35 次 turn/end 吻合。反过来，「有没有被重试」本身就是判别器：干净 413（INVALID_REQUEST）不重试，TRANSPORT 会重试。

3. 修复

补丁打在 home 层（$DSH_HOME/cordis.patch.yml），因为 home 层在所有 profile 的 bundle 栈之后应用；只改 profiles/web/cordis.patch.yml 覆盖不到 tui / headless。

# $DSH_HOME/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

注意：仅此一个配置项。插件的 Config schema 只有 enabled，没有体积上限选项。

4. 验证

YAML 语法校验通过；再用 DSH 自带的 --dump-config 打印合并后的配置树：

# == @deepseek-ai/dsh-base, patched by C:\Users\Temo Tee\.dsh\cordis.patch.yml
- id: session-log-deepseek
  name: '@deepseek-ai/dsh-session-log-deepseek'
  config:
    enabled: false
# == @deepseek-ai/dsh-base

与代码逻辑一致（L119 if (config.enabled !== true) return;），即请求体里不会再出现 dsh_session_log。

生效时机：Cordis 补丁层在启动时读取，需要重新启动 DSH。

5. 回滚

把 enabled: false 改回 true，或删掉这三行即可。

6. 保留该功能的替代方案

若确实希望继续上载会话日志，社区在 #7658 中提到 @argszero/cordis-plugin-session-log-budget 可为该字段加体积预算（本人未实测，仅供参考）。

7. 尚未完全解释的部分（如实说明）

1. 故障码与体积的出入（已解释）：现场全部是 TRANSPORT、没有干净的 413，这一点已由 @argszero 的源码复核解释清楚 —— TRANSPORT 是"非 LlmError"兜底（超 V8 字符串上限的 JSON.stringify RangeError），干净 413 走 INVALID_REQUEST 分支；两者重试行为不同（前者重试最多 5 次、后者不重试），这也解释了同一现象在不同会话里表现不一致。
2. 小字段会话同样失败：320272cd…（132 事件 / 0 MB）、5470aad8…（58 事件 / 0.1 MB）也报 TRANSPORT。禁用插件后若这些仍然失败，说明存在第二个独立原因。
3. 另一个独立问题：日志中存在 CONTEXT_WINDOW_EXCEEDED（status 400）——某次请求 messages 部分 793715 tokens、补全 256000、上限 1048576。这与本插件无关，属会话本身过长，需靠 compaction 或新开会话解决。

欢迎有相同现象的朋友补充：重启后小字段会话是否仍失败，以及是否复现过干净的 413。

8. 附带发现（与本问题无关，但会影响排查）

@deepseek-ai/dsh/lib/bin.js 的入口是：

if (import.meta.main) await runCli();

import.meta.main 在 Node 22.x 下为 undefined（本机 Node v22.16.0 实测：-e 与真实 .mjs 文件均为 undefined），于是 dsh 静默退出、无任何输出（exit code 0）：

$ dsh --version      # 无输出
$ dsh --profile web --dump-config   # 无输出

若排查时发现 dsh 命令「什么都不打印」，请确认所用 Node 版本（支持 import.meta.main 的运行时即可正常工作）。

---

English version (full)

Related discussions: #7736, #7658
Environment: Windows, DSH 0.1.7-rc.1, @deepseek-ai/dsh-session-log-deepseek@0.1.7-rc.1

TL;DR

@deepseek-ai/dsh-session-log-deepseek's enabled default was flipped from false to true in dsh-v0.1.6-alpha.1 (commit 31ec6bc7e3, 2026-09-14) — not in 0.1.7-rc.1. Fixed upstream in dsh-v0.1.7-rc.2 (commit 193f9ce413, PR #5168): Config.maxBytes defaults to 8 MiB, and the field is sent as the longest fitting prefix.
The plugin injects the entire session log as a top-level dsh_session_log field into every Messages request, and it is fail-closed with no request-size cap.
Once the acceptance watermark is invalidated, afterSeq falls back to -1, so every request re-uploads the whole log (97.4 MB measured here), which the endpoint rejects with HTTP 413. A 413 is never retried and never writes a watermark → permanent self-lock.

Fix (home layer, applies to all profiles):

# $DSH_HOME/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

---

1. Symptoms

• Sessions "keep timing out"; the Web UI hangs for a long time before erroring.
• The log shows this repeatedly:

turn/end   code = TRANSPORT
"DeepSeek Messages transport failed"          code = TRANSPORT
"DeepSeek API request to https://api.deepseek.com failed"   code = TRANSPORT

• Failures clustered on 2026-09-24 19:40–20:33 (UTC+8), 35 turn/end TRANSPORT events.
• The retry policy itself is fine, but its allowlist excludes INVALID_REQUEST:

policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]

2. Diagnosis

2.1 Network ruled out first

api.deepseek.com → CNAME d3bbv8sr76az5s.cloudfront.net resolves fine; TCP 443 reachable; WinHTTP has no proxy. The network is not the cause.

2.2 Key evidence in the session logs

Two large sessions had an acceptance watermark of 0 (i.e. nothing was ever accepted), yielding recomputed dsh_session_log fields of:

Session	Events	Watermark	Recomputed field size
3604e97a…	41624	0	97.4 MB
009a6a36…	41569	0	97.3 MB

2.3 Mechanism, confirmed from plugin source (dsh-session-log-deepseek/lib/index.js)

// L16   enabled by default (was false before 0.1.5-rc.2)
const Config = z.object({ enabled: z.boolean().default(true) });

// L96   version-scoped: a format migration invalidates every old watermark
if (acceptedFormatVersion !== session.header.version) continue;

// L119  when disabled, the field is never registered
if (config.enabled !== true) return;

// L127  afterSeq = -1 → snapshotEvents(0) → the whole log
const suffix = session.snapshotEvents(SessionLogOffset(afterSeq + 1));

The watermark is written only inside accept() after an HTTP 2xx. The README states it plainly:

No independent request-size cap — complete delivery is fail-closed; provider rejection leaves the cursor unchanged instead of truncating the log.

In other words: failure → no watermark → a larger resend next time → even more likely to fail. A loop that can only get worse.

2.4 Measured endpoint size threshold (decisive evidence)

Using the same key against the same endpoint, https://api.deepseek.com/anthropic/v1/messages, with graded request bodies (carrying a placeholder dsh_session_log field):

Request body	Result	Time
0 MB (control)	HTTP 200	886 ms
8 MB	HTTP 200	3628 ms
48 MB	HTTP 413 Failed to buffer the request body: length limit exceeded	22708 ms
96 MB	HTTP 413 (openresty)	843 ms

The threshold sits between 8 MB and 48 MB.

2.5 Why it surfaces as a "timeout" instead of a clean 413

In dsh-llm-deepseek the status mapping is:

• L1500: status === 400 || status === 413 → INVALID_REQUEST
• L1879: catch-all branch — any non-LlmError exception → TRANSPORT

Correction (thanks @argszero): the "drifting toward the idle watchdog" explanation is withdrawn — the watchdog maps to TIMEOUT (adapter.ts:44), and DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000 (5 min) is an order of magnitude away from the measured 22.7 s. The upstream decision note names the real cause: a log past the V8 string limit makes the merged JSON.stringify throw RangeError, which surfaces as TRANSPORT; the default retry policy then repeats the same serialization, so no request ever reaches a 2xx. Because TRANSPORT is retried up to five times, a 48 MB body can cost ~240 MB of upload per turn.

3. The fix

The patch goes in the home layer ($DSH_HOME/cordis.patch.yml), because the home layer is applied after every profile's bundle stack; editing only profiles/web/cordis.patch.yml would not cover tui / headless.

# $DSH_HOME/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

Note: that is the only knob. The plugin's Config schema exposes enabled and nothing else — there is no size-cap option.

4. Verification

YAML syntax validated, then DSH's own --dump-config was used to print the composed tree:

# == @deepseek-ai/dsh-base, patched by C:\Users\Temo Tee\.dsh\cordis.patch.yml
- id: session-log-deepseek
  name: '@deepseek-ai/dsh-session-log-deepseek'
  config:
    enabled: false
# == @deepseek-ai/dsh-base

Consistent with L119 (if (config.enabled !== true) return;) — dsh_session_log no longer appears in the request body.

When it takes effect: the Cordis patch layer is read at startup, so DSH must be restarted.

5. Rollback

Set enabled: false back to true, or delete the three lines.

6. Alternative if you want to keep the feature

For those who want to keep uploading session logs, discussion #7658 mentions @argszero/cordis-plugin-session-log-budget, which adds a size budget to the field (not tested by me; shared for reference only).

7. What is still not fully explained (stated honestly)

1. Failure code vs. size mismatch: every observed failure was TRANSPORT, with no clean 413. The measurements in 2.4 show oversized bodies produce a clean 413 rather than a connection reset, so size alone cannot explain all TRANSPORTs; "upload too slow, drifting toward the idle timeout" is the most plausible additional explanation, but I have not proven it directly in a reproduction.
2. Small-field sessions fail too: 320272cd… (132 events / 0 MB) and 5470aad8… (58 events / 0.1 MB) also reported TRANSPORT. If these still fail after disabling the plugin, there is a second, independent cause.
3. A separate issue: the log contains CONTEXT_WINDOW_EXCEEDED (status 400) — one request had 793,715 tokens in messages and 256,000 in the completion against a 1,048,576 cap. Unrelated to this plugin; the session is simply too long and needs compaction or a new session.

If you see the same symptoms, please chime in: do small-field sessions still fail after restart, and has anyone reproduced a clean 413?

8. Side finding (unrelated to this bug, but it will derail your debugging)

@deepseek-ai/dsh/lib/bin.js self-dispatches with:

if (import.meta.main) await runCli();

import.meta.main is undefined on Node 22.x (verified here on Node v22.16.0, both with -e and from a real .mjs file), so dsh exits silently with no output (exit code 0):

$ dsh --version                      # no output
$ dsh --profile web --dump-config    # no output

If the dsh command "prints nothing" while you are debugging, check which Node runtime is on PATH (any runtime that supports import.meta.main works fine).

[temotee2103]

非程序员也能照做的 3 步修复（照抄即可）

更新（2026-09-25）：本问题已在 dsh-v0.1.7-rc.2 修复 —— commit 193f9ce413（PR #5168）新增 session-log-deepseek.Config.maxBytes（默认 8 MiB），超大日志改为"只发水位之后最长的可容纳前缀 + 水位前移"，单个事件超限时省略字段并 warn。本指南适用于 ≤ 0.1.7-rc.1；rc.2 及以上无需关闭该插件。

结论：这是 DSH 自带插件 session-log-deepseek 从 dsh-v0.1.6-alpha.1（2026-09-14）起默认开启导致的（不是 0.1.7-rc.1）—— 它把整份会话日志塞进每次请求，记录一大就超过服务端上限；干净 413 不会被重试，而现场看到的 TRANSPORT 会被重试最多 5 次、每轮都重传整个字段，于是会话永久卡死。关掉它即可恢复（代价：模型失去"按需读取原始会话日志"的能力）。

---

第 1 步：打开配置文件

按 Win + R，把下面这行原样粘进去，回车：

notepad %USERPROFILE%\.dsh\cordis.patch.yml

（如果记事本是空白的，说明文件还不存在 —— 没关系，第 2 步写完内容后：文件 → 另存为 → 保存类型选"所有文件" → 文件名填 %USERPROFILE%\.dsh\cordis.patch.yml）

第 2 步：在文件最后另起一行，粘贴这三行

- id: session-log-deepseek
  config:
    enabled: false

三个注意点：

1. 行首不要加 #；
2. 缩进照抄：enabled 前面是 4 个空格（不要用 Tab）；
3. 如果文件里已经有 - id: session-log-deepseek，不要再加一遍 —— 只把它下面的 enabled: true 改成 enabled: false。

第 3 步：保存并重启

Ctrl + S 保存 → 关掉正在跑 dsh web 的窗口（或按 Ctrl + C）→ 重新运行 dsh web → 打开原来卡死的会话发一句话验证。

---

怎么确认生效（可选）

dsh --profile web --dump-config

输出里应能看到该条目为 enabled: false，并标注 patched by ...\.dsh\cordis.patch.yml。

想反悔：回滚

把这三行删掉，或把 false 改回 true，重启 DSH 即可。

---

一键脚本（不想手动改文件就用这个）

点开复制：粘进 Windows PowerShell（Win+R → powershell）回车即可

$PatchPath = Join-Path $env:USERPROFILE '.dsh\cordis.patch.yml'
$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
$dir = Split-Path -Parent $PatchPath
if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir -Force | Out-Null }

$block = @(
  '',
  '# session-log-deepseek must be OFF (flipped on by default since dsh-v0.1.6-alpha.1).',
  '# See deepseek-harness discussions #7658 / #7753.',
  '- id: session-log-deepseek',
  '  config:',
  '    enabled: false'
) -join "`r`n"

if (Test-Path $PatchPath) {
  $existing = [System.IO.File]::ReadAllText($PatchPath)
  if ($existing -match '(?m)^\s*-\s*id:\s*session-log-deepseek\s*$') {
    Write-Host '已存在 session-log-deepseek 条目，未修改。请确认它下面写的是 enabled: false' -ForegroundColor Green
    return
  }
  Copy-Item $PatchPath "$PatchPath.bak-$(Get-Date -Format yyyyMMdd-HHmmss)" -Force
  $new = $existing.TrimEnd() + "`r`n" + $block + "`r`n"
} else {
  $new = "# home-level patch layer`r`n" + $block + "`r`n"
}
[System.IO.File]::WriteAllText($PatchPath, $new, $utf8NoBom)
Write-Host "完成：已写入 $PatchPath" -ForegroundColor Green

---

还是不行？

1. dsh 命令什么都不打印 → 多半是 Node 版本问题：Node 22 下 import.meta.main 为 undefined，会让 dsh 静默退出。换 Node 24 / 20 再试。
2. 新会话也失败 / 报 CONTEXT_WINDOW_EXCEEDED → 那是上下文超限，属另一个问题，需要做压缩或新开会话。
3. 改完仍然失败 → 把报错原文（整段）贴到本贴或 [Bug] 会话格式迁移后 dsh_session_log 水位失效：每次请求重发整份日志 → 413 且永久卡死 #7658 下面；也可用 error.cause 区分是 Messages API 还是 Files API（带图片附件时走后者）。

[argszero]

Confirmed on source, with two corrections and one important piece of news for both the report and the step-by-step workaround in the comment above: 0.1.7-rc.2 already ships the bound you are asking for, so turning the plugin off is no longer the only way out — and the flip is one release older than the guide states. Details in the order your four points were made.

1. The default flip — confirmed, and its exact release

session-log-deepseek/src/index.ts:52 really is enabled: z.boolean().default(true), and apply() early-returns on config.enabled !== true (:183) — so the whole dsh_session_log contribution exists only when that default is on, which is also why the enabled: false patch in the comment above works: the field is then never registered at all.

One correction to the guide's attribution, though: the flip came in dsh-v0.1.6-alpha.1, not 0.1.7-rc.1 (git tag --contains 31ec6bc7e3 → dsh-v0.1.6-alpha.1; commit 31ec6bc7e3 "fix(session): keep upload defaults independent of test runners", 2026-09-14). That is one release earlier than the 0.1.7-alpha.2 comparison point, and it is the whole explanation for the two READMEs that appear to disagree: the wording changed together with the default. Anyone on 0.1.6-alpha.1 or later is affected, not only rc.1 users — worth fixing in the guide's first line and in the PowerShell script's comment.

2. The mechanism — confirmed, with the exact anchor

acceptedThrough() (:141-175) folds session-log-deepseek/delivery-accepted events only when acceptedFormatVersion === session.header.version (:159, deliberate), and documents its return as "greatest accepted sequence, or -1 before any accepted request" (:139). The watermark is written only inside the accept() callback (:233-239), which the adapter calls only after a successful HTTP response. With afterSeq === -1, session.snapshotEvents(SessionLogOffset(afterSeq + 1)) (:195) is snapshotEvents(0) — the complete log. So: fail → no watermark → next request is strictly larger → fails again. Your reading is right.

3. The watchdog attribution — this is not what produces TRANSPORT

The adapter builds an idle watchdog at adapter.ts:54, but its expiry is translated into TIMEOUT, not TRANSPORT:

if (timeoutOf(watchdog.signal, 'MESSAGES_IDLE') !== undefined) throw new LlmError('DeepSeek Messages stream idle timeout', 'TIMEOUT', …)   // :44
if (options.signal?.aborted) throw new LlmError('DeepSeek Messages request aborted', 'ABORTED', …)                                            // :45
if (error instanceof LlmError) throw error                                                                                                    // :46
throw new LlmError('DeepSeek Messages transport failed', 'TRANSPORT', { cause: error })                                                        // :47

TRANSPORT is the fallback for any non-LlmError — the watchdog cannot reach it (any watchdog-driven abort produces a TimeoutReason or an AbortError, neither of which is a "clean 413"). And the arithmetic does not fit either: DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000 (5 minutes, defaults.ts) versus your measured 22.7 s for a 48 MB upload — an order of magnitude apart.

The upstream fix's own decision note names the actual cause, and it is worth having: a log past the V8 string limit makes the adapter's merged JSON.stringify throw RangeError, the adapter reports TRANSPORT, and the default retry policy repeats the very same serialization — so no request ever reaches the 2xx that would advance the watermark. Below that limit, the note measures the other failure mode you hit: a 269 MiB first upload of a 96,341-event Session waited 34 s for its 2xx. So your 8 MB/48 MB probe brackets the provider threshold, while the field's own failure modes are "too slow" and "cannot be serialized" — not "idle".

One more consequence you can put in the report: TRANSPORT is on the retry whitelist (retry-policy.ts:17-23, DEFAULT_MAX_RETRIES = 5), so every failed attempt re-runs the same prepare and re-uploads the entire field. A 48 MB body therefore costs up to 240 MB of upload per turn — consistent with your 35 turn/end events in 53 minutes. The retry policy is right; the thing it retries is unbounded. This is also a useful diagnostic split against the guide's "被拒后又不重试": a clean 413 maps to INVALID_REQUEST, which is not on the whitelist and genuinely is not retried, whereas the shape you actually observed (TRANSPORT) is retried up to five times — so "retried or not" tells you which of the two the request really produced.

4. Your fourth point (small sessions): llm-deepseek has two TRANSPORT producers, not one

The second is a much better candidate for a 132-event session:

• adapter.ts:47 — "DeepSeek Messages transport failed" (the Messages request)
• files-api.ts:160 — "DeepSeek Files API request to <baseURL> failed" (the Files API path used when a session carries image attachments)

Discriminating them is cheap: look at error.cause (both carry one), and check whether the failing session has image/attachment content — if it does, the Files API branch is in play and the log has nothing to do with it. Note also that the small-session case cannot be the watermark lock at all: with enabled: true and no acceptance, even a 58-event session still sends the whole log, but that is a few KB — far below any provider limit.

5. 0.1.7-rc.2 already bounds this — the news

193f9ce413 "fix(llm): keep oversized request extensions from blocking model requests (#5168)" is an ancestor of tag dsh-v0.1.7-rc.2 (npm dist-tag next, already published). It is exactly the shape you would have designed:

• session-log-deepseek.Config.maxBytes, default 8 MiB — each request carries the longest post-watermark prefix whose serialized field fits, acceptance advances the watermark to that prefix's throughSeq, and later requests continue from there. Your "workaround" becomes a config value.
• A first event that alone exceeds the limit no longer fails the request: the field is omitted, logger.warn names the stuck event and the session, and the watermark stays put until it fits.
• The adapter no longer turns an unserializable merged body into a transport failure: it sends the base body without extension fields, skips the joint acceptance, and logs which fields were omitted. A base body that cannot serialize still fails — correctly.

So on rc.2 the permanent self-lock is gone, and the enabled: false step-by-step guide above becomes optional rather than the only remedy — worth saying so at the top of it, since the guide will otherwise keep circulating as the fix for a problem that is already closed upstream. If you are staying on 0.1.7-rc.1, the same semantics are available as a plugin: @argszero/cordis-plugin-session-log-budget@0.1.0 wraps the extension registry's prepare, budgets the field by bytes into a longest fitting prefix, and writes its own valid delivery-accepted accordingly. It composes with the built-in maxBytes rather than shadowing it (it awaits the owner's prepare first and only narrows the result), so on rc.2+ it just gives you a tighter budget; on ≤ 0.1.7-rc.1 it is the fix — and unlike switching the plugin off, it keeps the model's on-demand access to the raw session log that the guide lists as the price of the workaround.

npm i @argszero/cordis-plugin-session-log-budget@0.1.0

And for the measurement you had to do by hand — working out which field ate the request body — @argszero/cordis-plugin-request-body-accounting@0.1.0 records the per-field byte ledger the harness itself does not keep; in the same family it measured a 205,872,373-byte field against a 206,451,866-byte request body. Both are siblings of the wider thread in #7658, which owns the watermark mechanism.

Summary for your report: claim 1 stands (with dsh-v0.1.6-alpha.1 as the flip); the TRANSPORT-vs-413 explanation should be re-attributed from the watchdog to RangeError/fetch-level failure, with error.cause as the discriminator; and the item can be marked fixed on 0.1.7-rc.2 by #5168.