invalid pi-ai replay state: block count does not match assistant content after truncated output + continue

[Zhuchen00123]

Description

When a pi-ai-backed model response is truncated by max_tokens (stopReason length), the UI shows “已达到输出 token 上限回答被截断”. If the user then sends “继续” to continue the truncated assistant message, the next request fails with:

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

Environment

• DSH version: 0.1.0-rc.6
• OS: Windows + WSL2 (Debian)
• Provider: opencode-go / deepseek-v4-flash (pi-ai)
• Preset: custom code-wsl (PTC/Code Mode) with tool-bootstrap bootstrapMaxTokens: 1024 (later raised to 16384)

Steps to reproduce

1. Use a PTC/Code Mode preset whose first request has a small maxTokens cap (e.g. 1024).
2. Send a prompt that causes a long first response (e.g. a large run_code program).
3. The response hits the output token limit and is truncated.
4. Click “继续” / send “继续”.
5. The next turn fails with invalid pi-ai replay state: block count does not match assistant content.

Expected behavior

After a truncated assistant message, “继续” should resume cleanly, or the replay state should be discarded/rebuilt so the conversation can continue.

Actual behavior

The turn fails with an INVALID_REPLAY_STATE error and the conversation cannot continue from that truncated message.

Possible cause

toPiReplayState stores blocks from the pi-ai done message even when stopReason is length. When the harness later continues/edits the truncated assistant content, the durable assistant content block count no longer matches the saved replay state blocks, so replayedAssistant rejects with block count does not match assistant content.

Workaround

• Avoid using “继续” after truncation; send a new message instead.
• Increase the output token cap so truncation is less likely.

Related

• The replay state validation is in @deepseek-ai/dsh-llm-pi-ai: replayedAssistant checks state.blocks.length !== message.content.length.

[argszero]

Your reproduction adds the missing trigger to a mechanism that was already diagnosed on #1627 (same error, denial123789 traced it). I verified the full chain against current master (47f9438) — your "possible cause" is exactly right, and the failure point is one function.

1. The mechanism, end to end

• toPiReplayState (llm/llm-pi-ai/src/replay.ts:63-91) projects blocks from the pi-ai done message's content, and stream.ts:188-195 calls it regardless of stopReason — so a length-truncated response gets a replay state frozen at the truncated block count. (This is the 到达输出 token 上限时，出现“本轮运行失败invalid pi-ai replay state: block count does not match assistant content” #1627 root cause.)
• The replay state is durable metadata on the assistant message. When you send "继续", the harness extends that same assistant message's durable content — appending/rewriting blocks beyond what the frozen replay state recorded.
• On the next request, replayedAssistant (replay.ts:160-167) walks the durable content and requires a per-index match against state.blocks: const replay = state.blocks[index]; if (replay === undefined || replay.type !== block.type) return invalidReplay(...) — the first continued block (index beyond the truncated state) hits replay === undefined → invalid pi-ai replay state: block count does not match assistant content → INVALID_REPLAY_STATE, and the turn dies.

So the truncation alone does not corrupt; the continue action does — it mutates durable content that the replay state assumed immutable.

2. Why the divergence is structural, not a one-off bug

replayedAssistant demands the replay state mirror the durable content exactly. Three distinct mutation paths violate that invariant: continue-after-truncation (yours), compaction rewriting assistant content, and any future edit/resume path. #1627's report was the truncation side; yours is the continue side — same invariant, two triggers.

3. Fix directions

• Primary (the continue path must invalidate/re-project the state): when the harness extends a truncated assistant message, it should clear that message's durable replay state (the message then falls back to foreignAssistant at replay.ts:124-129, which rebuilds it losslessly) or re-project the state from the post-continuation content. The replay state is a projection, not a source of truth — the content is.
• Defense-in-depth (tolerate divergence in replayedAssistant): the per-index loop could stop at Math.min(content.length, state.blocks.length) and treat the excess durable blocks as foreign instead of failing the whole turn. That makes the adapter resilient to any future mutation path — but it changes the failure semantics from "hard error" to "partial replay," so it deserves a deliberate decision rather than a silent fix.
• A cheaper mitigation for the immediate report: on "继续" after a length truncation, drop the replay state at the client/agent boundary (same effect as the primary fix, smaller surface).

4. Classification note

This is not a session-log corruption (the durable log is intact — the content is fine, the metadata is stale). It belongs to the same class as #1627 and my #1593 serializer-family work: durable content and its side-channel metadata can diverge, and the adapter hard-fails instead of degrading. Worth folding into one "replay-state coherence" workstream with #1627.

Thanks for the precise repro — the continue trigger was the missing half of the picture.

[Zhuchen00123]

Thanks for the detailed diagnosis — this matches exactly what we saw with the code-wsl PTC preset.

A quick practical note for anyone hitting this before the fix lands:

• We raised the bootstrap maxTokens cap from 1024 to 16384 in our preset, which makes first-request truncation much less likely.
• If truncation still happens, sending a new message instead of clicking “继续” avoids the stale replay-state path entirely.

Happy to help test a patch if you open a PR for the “drop/re-project replay state on continue” fix.