【Bug】达到最大输出长度时会话被永久写坏：后续每轮都报 invalid pi-ai replay state: block count does not match assistant content

[HandleCoding]

【Bug】达到最大输出长度时会话被永久写坏：后续每轮都报 invalid pi-ai replay state: block count does not match assistant content

环境

• dsh 0.1.0-rc.6（当前 npm 最新发布版），macOS
• 模型 glm-5.3，经 catpaw 以 anthropic-messages 协议接入
• 从原理上看，任何走 pi-ai 适配、且截断时正在输出工具调用的 provider/模型都可能触发

现象

1. 某一轮回复达到最大输出长度，本轮以失败告终（此时模型正在发射 tool_use 块）
2. 之后在同一会话里无论输入什么（包括「继续」），每一轮都立即失败，报错：

   本轮运行失败 invalid pi-ai replay state: block count does not match assistant content
   

3. 由于坏消息已持久化，该会话（以及从它 fork 出的新会话）永久不可用

根因分析

截断那一轮的持久化 assistant/message 实测数据（来自 session.jsonl.zstd）：

content:      2 blocks  [reasoning, text]
replayState:  4 blocks  [reasoning, text, tool-call, tool-call]
stopReason:   length

链路如下：

1. provider 返回 stop_reason: "length" → finish chunk 的 reason 映射为 { kind: 'max-tokens' }
2. packages/llm/llm/src/assembler.ts 的 BlockAssembler.blocks()：当 finish.kind === 'max-tokens' 时会过滤掉所有 tool-call 块（截断的工具调用不能安全执行）——这个行为本身是对的
3. 但同一个类里的 replayState getter 原样返回 finish chunk 附带的 adapter replay state，其 blocks 仍描述上游完整块列表（含被过滤的 tool-call）
4. agent loop（packages/core/agent-loop/src/agent.ts 组装 assistant/message 处）把「过滤后的 content + 未过滤的 replayState」一起持久化，产生了自相矛盾的消息
5. 下一轮构建请求时，packages/llm/llm-pi-ai/src/replay.ts 的 replayedAssistant() 逐块校验 state.blocks.length === message.content.length（4 ≠ 2），抛出 INVALID_REPLAY_STATE
6. 校验每次都失败 → 会话永久损坏

建议修复

在 assembler 侧：当 max-tokens 过滤真的丢弃了 tool-call 块时，同步丢弃 replayState。该消息随后会回退为 foreign assistant 回放（foreignAssistant 路径），永远合法，只是损失签名信息：

get replayState(): unknown {
  // Max-token truncation drops tool-call blocks from `blocks()`; the adapter
  // replay state still describes the full upstream block list and can no
  // longer be paired with the filtered content. Dropping it lets the message
  // replay as a foreign assistant message instead of failing validation.
  if (this.finish.kind === 'max-tokens' && this.hasToolCallBlocks()) return undefined
  return this._replayState
}

private hasToolCallBlocks(): boolean {
  for (const partial of this.partials.values()) {
    if ((partial.block?.type ?? partial.blockType) === 'tool-call') return true
  }
  return false
}

注意只读 blocks() 也能判断，但 blocks() 对未知未闭合块类型会抛错，getter 里用 partials 判断可以避免引入新的抛错路径；纯文本截断（无 tool-call）时 replayState 应保留，避免不必要的签名损失。

两点补充建议（可选）

1. 存量坏会话的恢复：replayedAssistant() 遇到块数不匹配时，是否可以考虑降级为 foreign 回放 + warning，而不是抛错把会话永久 brick 掉？保持校验严格没问题，但失败最好可恢复。
2. 我本地已通过直接裁剪 session 日志里那条消息的 replayState.blocks（去掉多余的 tool-call 条目，保留前缀对齐的 reasoning/text 签名）修复了自己的会话，验证了该修复方向有效——修好后「继续」能正常续跑。

感谢！

[weijiafu14]

你和 #1263 是同一个 bug 的两份独立报告，而且证据正好互补：你这边有持久化产物的实测数据（content 2 块 vs replayState 4 块、stopReason length），那边有源码级链路（toPiReplayState() 投影全部块 vs BlockAssembler.blocks() 按 finish reason 过滤）。合在一起基本就是一份完整的缺陷报告了，建议维护者一起看。

你多给出的一条事实值得单独强调：从坏会话 fork 出来的新会话也是坏的。也就是说 fork 不是逃生口——这把"一次截断报废一条会话"升级成"报废一整条血缘"，严重程度比单条会话高。

能做的

1. 已经坏掉的救不回来。 replayState 已经落进 session.jsonl.zstd，换配置、换路由都不修复既有记录。那条会话（以及它的 fork）只能弃掉，或者手工修日志。

2. 预防：把 maxTokens 声明成真实值。

触发条件是"输出被 max-tokens 截断，且截断点正好落在工具调用上"。自定义 provider 没显式声明 maxTokens 时走的是通用路由兜底值，跟端点真实上限对不上就会提前截断——等于人为抬高了踩中的概率：

llm-pi-ai:
  providers:
    你的catpaw路由:
      models:
        - id: glm-5.3
          contextWindow: <真实上下文窗口>
          maxTokens: <该模型真实的最大输出>

这不修 bug，只是让截断少发生。对"后果是会话报废"这种量级，降低触发频率是有意义的。

一条我不建议你走的路

有人会想到"换一条不经过 dsh-llm-pi-ai 的路由，就不产生 replayState 投影"。结构上说得通，但我没有实测过——具体说，我没验过"截断正好落在 tool call 中途"这个场景下另一条路由的持久化产物长什么样、会不会有它自己的一致性校验。在有人真做过这个对照实验之前，那是推断不是方案，我不拿它当建议。

（这条正好指向我自己维护的东西，所以更该说清楚。）

边界

我们不修 dsh-llm-pi-ai。你指出的那个不对称——一边投影完整块列表、另一边按 finish reason 过滤，两者都"对"，但没人负责让它们一致——是个真实的契约裂缝，而且它的后果是终态、无重试、连血缘一起报废。我认为严重度高于多数流式解析类 bug。

利益相关：我维护 pi2dsh；上面第 2 点是 DSH 官方配置，跟我的包无关。