Session history replay truncates after edit-and-resend of a message on legacy-schema long sessions (data intact, UI stops rendering earlier checkpoint) #61189

Description

Title: Session history replay truncates after edit-and-resend of a message on legacy-schema long sessions (data intact, UI stops rendering earlier checkpoint)

Labels (suggestion): bug, desktop, maybe triage

Bug description

In a long-running session (2 days old, legacy storage structure predating the part migration), using the retract / edit-and-resend action on an earlier user message caused the session history replay (UI) to stop rendering at a much earlier checkpoint — every agent message after that old checkpoint is invisible in the UI, including the re-sent message itself.

Important: this is display-only. The agent's internal context kept working correctly, all subsequent tool calls and file changes happened, and everything is present in local storage (opencode.db). Nothing is lost — only the history replay in the UI no longer shows the tail of the conversation.

Reproduction in a fresh short session failed (session stored in the new part schema), which suggests the trigger is the combination of (a) legacy session_message-stream sessions and (b) the revert flow created by edit-and-resend.

Environment

• OpenCode: 2.2.5 (desktop client, latest channel)
• OS: Windows 11 x64
• Client: desktop app; HTML preview opened via Review pane
• Affected session profile: 2 days of activity, ~30 user/agent exchanges, 22+ background subagent dispatches (incl. 1 task_cancel, 1 task_revive), local sqlite opencode.db grew to ~11.8 GB

Steps to reproduce

1. Continue a long-running session created before the session_part/part storage migration (its messages live in the legacy session_message stream table), with heavy tool/subagent activity.
2. Use retract / edit-and-resend on an earlier user message (a session.revert.stage → session.revert.commit flow; the re-sent message gets a new message id).
3. Continue normally for 10+ exchanges (agent replies, tools run).
4. Reopen the session view / scroll back through history.
5. History replay stops at an agent message from before the revert; all later messages (including the re-sent one and subsequent agent replies) are missing from the UI.

Expected vs Actual

• Expected: replay shows the resent message and everything after it.
• Actual: replay stops at a stale checkpoint; tail of the conversation is invisible in UI, while the agent continues working and storage records everything.

Evidence from local storage (SQLite opencode.db, read-only queries)

For the affected session:

-- message stream intact and contiguous:
SELECT COUNT(*) FROM session_message WHERE session_id = '<affected-session-id>';  -- 503 rows, seq spans normally
-- legacy schema: no rows in the migrated structures for this session:
SELECT COUNT(*) FROM message      WHERE session_id = '<affected-session-id>';  -- 0
SELECT COUNT(*) FROM session_part WHERE session_id = '<affected-session-id>';  -- 0

Server log confirms the flow on the affected session:

session.revert.stage   messageID=msg_<retracted-message-id>   (retract action)
session.revert.commit                                          (few minutes later)
-- subsequent exchanges got new message ids and appended to the stream normally

So the launcher-side data is complete; the replay UI does not render it.

Hypothesis (unverified)

The history replay renderer reads the migrated part-based chain (or an inconsistent subset) instead of the legacy session_message stream for sessions that still live in the old schema — reverting/branching on such a session moves the expected chain beyond what the renderer walks, so it renders up to a stale checkpoint.

Impact & workaround

• Impact: audit/history view only (display misled the user into thinking the conversation was lost). Agent execution, storage, and disk artifacts are unaffected; the current-position view (newest messages) still works while streaming.
• Suggested workaround: avoid edit-and-resend on legacy sessions; start a fresh message instead.