[Bug]: OpenCode 2.1.2 rollback fails decoding compaction history: missing recent field#22656

opened10d agobyRraulferrodrigues

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Use T3 Code with OpenCode CLI/server 2.1.2.
  2. Open an existing conversation containing completed context compactions.
  3. Attempt to roll back to an earlier message.
  4. Observe the rollback error. Retrying produces the same result.

Expected behavior

The conversation rolls back to the selected checkpoint.

Actual behavior

T3 displays:

1The provider could not roll back this conversation. Try again;
2if it keeps failing, check the provider and server logs.

Three attempts each retried five times, all failing with:

1ProviderAdapterRollbackThreadError
2 caused by ClientError
3 caused by SchemaError: Missing key
4 at ["data"][89]["recent"]

Impact

Major degradation or frequent failure

Version or commit

0.1.2-nightly.20261021.3457, e64766c56ac6

Environment

Linux x64, T3 Code Nightly desktop, OpenCode 2.1.2.

Logs or stack traces

shell
1

Screenshots, recordings, or supporting files

No response

Workaround

No response

Synced from GitHub

Investigation:

T3 bundles @opencode/client and @opencode/protocol 2.0.28. Its compaction-message schema requires a top-level recent string.

The OpenCode 2.1.2 history endpoint returns that value inside metadata.recent. This was confirmed against the actual HTTP response. Entry 89 is a completed compaction, and its metadata.recent matches the value stored in OpenCode’s database.

The history request returns HTTP 200, but T3 rejects its response during decoding. No revert request is sent.

This is from GPT-6.1-Sol.

Reproduced with a real OpenCode 2.1.2 server on 4f651cb10d: HTTP history returned successfully, but decoding failed at data[3].recent. On b2c65dcc8a, native and legacy compaction histories decode, and rollback through the dev server succeeds with the expected retained-message boundaries. Nine focused tests pass. Fix: #22661.

Synced from GitHub

Forking from a turn fails the same way, not only rollback. Seen on 0.1.1-nightly.20261020.3411 with OpenCode 2.1.0 and on 0.1.3-nightly.20261023.3553 with OpenCode 2.1.3.

The fork boundary reads the source session's messages, so a thread that was compacted once can't be forked from an earlier turn. The new thread's first turn fails ("Provider turn failed") with ProviderAdapterForkThreadError caused by SchemaError: Missing key at ["data"][61]["recent"], and OpenCode never creates the forked session. On my main machine it happened on a long thread with automatic compactions.

Small repro: an OpenCode thread with two turns, then /compact, then one more turn, then fork at turn 2. OpenCode stores the compaction without recent.

Filling recent into the history page the way #22661 does fixes it. I tried the same fill as a local stopgap: the fork then works and recalls only the first two turns. So #22661 covers forks too.

Model and harness: Claude Opus 5.5 via OpenCode 2 in T3 Code.