大会话分叉后所有请求永久 413：dsh_session_log 重传整份继承日志，撞上游约 50 MB 请求体上限

[Gy000012]

摘要

对一个规范日志较大的会话执行"分叉（fork / seeded session）"后，新会话里任何请求都会失败，包括 /compact：

DeepSeek Messages request failed (413)   code=INVALID_REQUEST   status=413

而且不会自愈：不是偶发，而是每次请求都必然失败。

根因：默认开启的 session-log-deepseek 会随每个官方 API 请求上传"上次被服务端接收之后的规范会话日志"。分叉会话的"已接收水位"永远是 -1（下面有测量方法），于是第一个请求就把继承来的整份日志塞进请求体（实测 48.8 MiB），超过上游网关约 50 MB 的 body 上限被拒；又因为 413 归类为不可重试、且非 2xx 不写接收水位，水位永远不推进 ⇒ 每个后续请求重传同一份 48.8 MiB ⇒ 永久死锁。

环境

• DSH dsh-v0.1.6-alpha.1（commit 0a15e36e7f）；master 上相关代码仍在（2026-09-20 核对）
• 主机：Windows 10 Pro 19045 / Node 24.16.0（该问题与操作系统无关，取决于会话日志大小与上游 body 上限）
• 模型/协议：deepseek-official / deepseek-flash，Anthropic Messages 兼容端点 https://api.deepseek.com/anthropic/v1/messages
• 会话关系：fork 由会话分叉创建（isSeeded: true，parentSession 指向父会话），父子都在本机

复现

1. 让一个会话不断工作，直到其规范日志累计到 ~49 MiB（长期会话很容易达到；本次是 15,121 条事件）；
2. 从它分叉出一个新会话；
3. 在新会话里发任意一条消息 → 413；再执行 /compact → 同样 413。

期望：分叉会话可以正常工作（哪怕退化成"这一轮不带日志字段"或"分片上传"）。
实际：永久失败，而且错误信息完全看不出原因。

关键证据

1) 分叉会话的已接收水位恒为 -1

水位由 acceptedThrough(session) 折叠日志中的 session-log-deepseek/delivery-accepted 事件得到，且要求 data.sessionId === session.id（packages/session/session-log-deepseek/src/index.ts:146）。

测量方式（注意 session.v3.jsonl.zstd 是多帧 zstd，逐帧解压才能拿到完整 JSONL）：

• 该 fork 日志里共有 1,706 条 delivery-accepted，全部写的是父/祖父会话 id，写它自己的一条都没有 ⇒ 水位 = -1。
• 对照：同一时刻父会话的水位是 15,368，因此每个请求只带 4 条事件 ≈ 18 KB，请求 200 OK —— 父会话此时上下文已达 ~755k tokens 仍完全正常 ⇒ 与上下文长度、模型、图片都无关。

2) 首个请求的载荷 ≈ 48.8 MiB

按 wire 结构累加分叉会话全部 15,121 条事件 ≈ 48.8 MiB，再加约 3 MB 模型输入 ≈ 52 MB。

3) 上游 body 上限约 50 MB（十进制）/ ≈47.7 MiB

直接对同一端点做体量探针（无模型输入，仅 body 大小）：

请求体	结果
45 MiB	200
48 MiB	413 Failed to buffer the request body: length limit exceeded（text/plain）
51 MiB	413 Request Entity Too Large（openresty，text/html）

再用该 fork 的真实日志内容作为 dsh_session_log 字段复现：字段 40 MiB（体 44.2 MiB）→ 200；字段 47 MiB（体 51.8 MiB）→ 413。

4) 失败闭环

• packages/llm/llm-deepseek/src/protocols/messages/transport.ts:33：HTTP 413 ⇒ 归类 INVALID_REQUEST，不可重试。
• 插件 README 的 Acceptance and retry 一节明确：非 2xx 不追加 delivery-accepted ⇒ 水位保持 -1。
• /compact 也是带 live sessionId 的请求 ⇒ 携带同一个超大字段 ⇒ 同样 413（日志中两次 compact 尝试均以同样错误结束）。

根因

session-log-deepseek 的 prepare() 每次都把 afterSeq + 1 .. throughSeq 的完整后缀塞进 dsh_session_log，没有任何字节上限。README 的 Known Limitations 自己也写了：

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

叠加 fork 语义（README:37："Forked sessions ignore inherited parent watermarks"）后，结果就是：日志大的会话一旦分叉，新会话一出生就不可用，且没有任何用户侧恢复手段（连压缩都失败）。

另外，错误面也不友好：网关的 413 响应不是 JSON，providerError() 只能回落到 DeepSeek Messages request failed (413)，用户完全看不出是"日志字段太大"。

我们认为这不是使用姿势问题：该组合结果本可以优雅降级，却没有降级。

建议修法（低风险、不丢数据）

1. 按字节截窗（推荐）：字段语义本身就允许只发连续前缀（afterSeq + 1 .. throughSeq）。给字段设一个安全上限（例如 32 MiB，远低于 ~47.7 MiB 的网关上限），throughSeq 取实际包含的最后一条事件。水位会随着每次成功请求逐步推进：既不丢数据，也不会死锁。
2. 或/并且：seeded session 的继承前缀视为已投递。若父会话对 seedLength 之前的事件已有可核验的接收记录，则从 seedLength - 1 起算，避免把几十 MB 重复上传一遍。
3. 错误可读性：当 provider 因 body 过大而拒绝时，给出明确诊断（例如提示 "session log suffix too large: X MiB"），并考虑让该情况可降级（跳过字段并继续本轮请求），而不是归类为终态 INVALID_REQUEST。
4. 补测试：构造"后缀远超上限"的会话，断言请求体会被截断或跳过，而不是原样发出。

临时绕过

• 在 profile 覆盖层里关掉该贡献（~/.dsh/profiles/<profile>/cordis.patch.yml）：

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

然后重启 dsh ⇒ 请求体回到约 3 MB，分叉会话立刻可用。代价是全局不再上传会话日志。

• 或者：不要分叉日志很大的会话（继续用原会话不受影响）。