Failed/interrupted assistant turn corrupts session — persistent INVALID_REPLAY_STATE on continue (llm-pi-ai)

[ssv-asia]

This has been written by AI.

Summary

When an assistant turn fails or is interrupted mid-stream, the session appears to persist a partial assistant message. Afterwards, every attempt to continue the conversation fails with:

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

The conversation becomes permanently unrecoverable — retrying "continue" reproduces the same error every time. Starting a new session is the only workaround.

Steps to reproduce (observed)

1. Cause an assistant turn to fail mid-generation (e.g. the upstream provider returns a 429/rate-limit, or the stream is interrupted before the assistant message is finalized).
2. Attempt to continue the same conversation.
3. It fails with INVALID_REPLAY_STATE; repeating step 2 keeps failing identically.

Expected: A failed/interrupted turn should not commit an incomplete assistant message; the partial turn should be rolled back so the session stays replayable and the user can retry.

Actual: The partial assistant content is retained, so the stored block count no longer matches the assistant content, and the llm-pi-ai adapter rejects every subsequent replay.

Possible direction: Commit the assistant turn atomically only on successful completion (or discard partial content during error handling), so replay-state validation never sees a mismatch.

Environment: adapter @deepseek-ai/dsh-llm-pi-ai, dsh 0.1.0-rc.5. Observed on a downstream build — happy to help narrow it down if it doesn't reproduce on a clean checkout.

[sylvesterkaczmarek]

This looks like something current main already fixes.

There's an implemented Aug 15 replay-state fix for exactly INVALID_REPLAY_STATE: block count does not match assistant content. Replay metadata is now kept aligned with the blocks that are actually persisted, and old/misaligned replay state degrades to provider-neutral replay instead of permanently breaking the session.

Since you're on rc.5, I'd first retry the affected session with a build containing that fix. If the previously poisoned session can continue there, it should confirm this is the same bug. If current main still fails, then your interrupted-stream case may expose a second path worth isolating.