fix: make revert boundaries chronological

[opencode-agent]

Summary

• truncate staged and committed revert views by the boundary message’s chronological array position
• stop comparing opaque message IDs in the App and TUI clients
• cover the timestamp rollover shape where a later message ID sorts before an earlier one

Checks

• bun test src/context/server-session.test.ts (packages/app)
• bun test test/cli/tui/data.test.tsx test/cli/tui/session-rows.test.ts (packages/tui)
• bun typecheck (packages/app)
• bun typecheck (packages/tui)
• bun test ./e2e/performance/unit (packages/app; 45 pass before/after)

Requested by: @thdxr (Dax via Slack)

[Enough1122]

Good catch — comparing message IDs lexically (id < to) only worked while IDs happened to sort chronologically, and the updated fixtures (msg_fff before msg_000) pin down exactly that failure mode. Switching to identity-based findIndex + slice is the right call.

One behavior change worth a closer look:

1. Boundary-not-found fallback: previously the comparison always produced some partition. Now, when event.data.to isn't present in the local list, input keeps everything and removed is empty (boundary < 0 ? items : ..., removed = []). That's correct when all local messages precede the boundary, but in a partial-hydration scenario where the boundary itself was never fetched (everything local sits after it), stale messages stay visible until server reconciliation catches up. The projectV2 pass may heal this, but it would be good to either confirm that path covers it or add an explicit test for "revert target missing from local state".
2. Ordering assumption: slicing relies on the input/message lists being chronological. That seems to be an existing invariant, just calling it out since the old code didn't depend on list order.
3. Nice consistent treatment across server-session.ts, TUI data.tsx, and rows.ts — including the matching === in the draft splice. The duplicated test updates in both app and TUI suites give this solid regression coverage.

LGTM modulo the not-found edge case above.

[Enough1122]

AI code review - automated review for reference; please use your judgment.

• packages/app/src/context/server-session.ts:1044-1056 - when the boundary message id is not present in local state (e.g. outside the 200-message fetch window or already pruned), the new code keeps everything (boundary < 0 -> unchanged) whereas the old id-comparison still trimmed. Safer against false removals, but the UI can show reverted messages until the next reconcile - consider falling back to a time comparison using the events created timestamp.
• packages/tui/src/routes/session/rows.ts:55-57 - revertBoundary() referencing an unloaded message renders the full history including reverted content until hydration catches up; same fallback consideration as above.
• Test updates using deliberately non-chronological ids (msg_fff/msg_000) nicely prove the fix targets ordering-independence - good.

[CasualDeveloper]

I tested the missing-message case mentioned above. It still causes problems on current v2.

OpenCode loads long conversations a page at a time. If the message selected for undo is on an older page that has not loaded yet, the App and TUI can keep showing messages that the undo should hide.

Pressing undo again can also fail when the selected message is the first message on the current page. OpenCode needs the message before it, but that message is still on the previous page.

I added tests and fixes on CasualDeveloper/opencode@fix/revert-consistency. That branch contains other undo fixes too, so I do not want to add all 41 changed files to this PR without asking first.

Would you prefer that I separate this message-loading fix and add it to #42461, or wait for #42461 to merge and open a small follow-up PR?

[CasualDeveloper]

Replaced by #46974. That PR is based on current v2, includes this boundary fix, and adds the paginated-boundary reconciliation flagged above, so this one can be closed.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.