core: continuing a V1-created session fails with UNIQUE constraint on event seq #52395

Summary

After upgrading from OpenCode 1.18.20 to 2.0.20, continuing a session that was created under V1 permanently fails: every event insert for that session hits UNIQUE constraint failed: event.aggregate_id, event.seq. The event_sequence row for the session is behind the actual max(seq) in the event table, so writes can never succeed and the session becomes write-dead (messages sent to it are not persisted).

Environment

• opencode version: 2.0.20 (channel: latest)
• OS: macOS Darwin 25.5.0, arm64
• Terminal: tmux (TERM=tmux-256color, COLORTERM=truecolor)
• Shell: /bin/zsh
• Install/channel: latest
• Active plugins: @tarquinen/opencode-dcp@latest

Reproduction

1. Use opencode 1.18.20 (SQLite-based storage in ~/.local/share/opencode/opencode.db) and create a session.
2. Upgrade to opencode 2.0.20 and reopen the same session.
3. Send a message.
4. Observe the error in ~/.local/share/opencode/log/opencode.log:

EffectDrizzleQueryError: Failed query: insert into "event" ("id", "aggregate_id", "seq", "type", "data") values (?, ?, ?, ?, ?)
cause: SQLiteError: UNIQUE constraint failed: event.aggregate_id, event.seq

Expected Behavior

V2 should resume the per-session event sequence for pre-existing (V1-created) sessions at max(seq) + 1, or re-sync event_sequence with the event table on startup, so V1 sessions can be continued.

Actual Behavior

V2 inserts events at sequence numbers that already exist for the aggregate, so every write fails. The session cannot accept new messages.

Observed for session ses_f1066f4c8ffeSqEdL7iA67Ujnf (created 2026-09-29 under 1.18.20, directory ~):

• event_sequence row for that aggregate: seq = 558
• event table for that aggregate: 624 rows, max(seq) = 678
• Errors logged at 2026-09-30T00:16:36Z and 2026-09-30T00:21:58Z:

timestamp=2026-09-30T00:21:58.895Z level=ERROR message=failed error="EffectDrizzleQueryError: Failed query: insert into \"event\" ... (cause: SQLiteError: UNIQUE constraint failed: event.aggregate_id, event.seq)"

Additional Context

• The 1.18.x V1 line already used the same SQLite DB, so this looks like V2 initializing/tracking the per-aggregate sequence independently of rows written by V1.
• Workaround: do not continue V1-created sessions; start new ones.
• Everything else works: the session list is intact (3,700+ sessions readable), only writes to affected sessions fail.