Failed invalid pi-ai replay state: block count does not match assistant content

[sauravfouzdar]

When a turn is truncated by max_tokens, BlockAssembler.blocks() intentionally drops every tool-call block from the durable message content they "cannot be executed safely" if truncated. But toPiReplayState called from stream.ts:193 with the raw, unfiltered pi-ai message keeps those tool-call blocks in its blocks array. So the durable content and its replay metadata end up with different lengths. The next time that message is replayed as history, replayedAssistant hits state.blocks.length !== message.content.length and throws the error.

[nkhanhquoc]

get same issue. How to continue process?

[weijiafu14]

先回 @nkhanhquoc 那句没人答的 "How to continue process?" ——这条帖子里最需要答案的就是它。

给被卡住的人：先试有 8 月 15 号那个修复的构建

隔壁 #2913 是同一个错误的另一份报告，@sylvesterkaczmarek 在那边指出：主干上已经有一个 8 月 15 日的 replay-state 修复，专门针对 INVALID_REPLAY_STATE: block count does not match assistant content，而且关键在于它的处置方式——

旧的/错位的 replay state 会降级成 provider-neutral 的重放，而不是永久性地弄坏这个会话。

也就是说，升到带那个修复的构建之后，已经被污染的会话有可能直接就能继续，不需要重开。这是目前最值得先试的一步。

如果升上去还是失败，那说明这条路径（本帖定位的 max_tokens 截断）和 #2913 的路径（流被中断）不是同一条——@sylvesterkaczmarek 在那边也留了这个可能性。真出现这种情况，本帖楼主给的定位就是最好的排查起点，值得回来更新。

（我没有在被污染的会话上实测过这个升级恢复，上面是转述 #2913 里的结论加上我自己的理解。真跑通了或者没跑通，都请回来说一声——这帖下面还有人等着。）

楼主这份定位里，最值得单独拎出来的一点

你把根因写得很干净：

• BlockAssembler.blocks() 在截断时有意丢掉 tool-call 块（截断的工具调用执行不安全，这个决定是对的）；
• toPiReplayState 拿的却是未经过滤的原始消息，于是 blocks 数组里还留着那些块；
• 两者长度对不上，下次重放时 replayedAssistant 抛错。

真正的教训不在"少过滤了一次"，而在这两个东西是从同一份数据的两个不同版本各自派生出来的：一个来自过滤后的内容，一个来自过滤前的输入。只要派生源不同，两者迟早会漂移——今天是截断触发，明天可能是别的什么过滤规则。所以更稳的形状是让 replay state 从最终持久化的那份内容派生（或者干脆由 blocks() 一次产出两者），而不是各自算一遍再校验是否相等。

而这个校验的失败模式，是本帖真正的伤害

state.blocks.length !== message.content.length 这个检查本身是对的——它确实发现了一个真实的不一致。问题是它发现之后只会抛错，没有任何恢复路径，于是一个本可修复的元数据错位变成了会话永久报废。

这个形状我这两天在社区里见到第四次了：

帖	防御性检查	因为没有恢复路径而变成
本帖 / #2913	replay 块数不匹配 → 抛	会话永久无法继续，只能新开
#3561	会话含图片就拒绝切到文本模型	视觉模型额度用完后没有任何可用模型，窗口卡死
#3568	工具参数解析失败 → 退化成空 {}	server 报"缺参"，模型原样重发，17 步死循环
#3489	MCP 会话过期 → 当普通工具错误抛	模型重新规划 61 次，500 多秒

四条的检查都是对的，四条的后果都比它们防住的东西更糟。共同缺的是同一样东西：检查发现不一致之后，除了"停"以外还能做什么。

而 8 月 15 号那个修复的做法恰好印证了这一点——它没有去消灭不一致，它是给不一致加了一条降级路径（退回 provider-neutral 重放）。这是这一类问题的通用解法，不是这一个 bug 的特例。如果有人在整理这类反馈，我觉得"防御性检查必须带恢复路径，否则它就是个陷阱"值得作为一条独立的设计准则提出来，比逐个修四个地方管用。

边界与利益相关

我们不修 DSH 自家组件——llm-pi-ai 的 replay state、BlockAssembler、会话持久化都在 DSH 里。上面全是转述、归纳和跨帖串联，没有一行是我能替你们落地的。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——会话被污染之后，装任何第三方插件都不会让那个 replay state 重新对齐。