Bug: stale event sequence permanently rejects new session events #51411

Activity

1. github-actions

   assigned

   rekram1-node

   on Sep 25, 2026
2. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue might be a duplicate of existing issues. Please check:

   • #51316: reports the same UNIQUE constraint failed: event.aggregate_id, event.seq error and a permanently unusable session after retries. It attributes the collision to concurrent sequence assignment, while this issue describes a stale event_sequence cursor.
3. d4n-sec commented on Sep 25, 2026

   

   d4n-sec

   on Sep 25, 2026

   Author

   More actions

   Thanks for the duplicate check. #51316 and this report share the visible failure (UNIQUE constraint failed: event.aggregate_id, event.seq) and the permanent retry behavior, but they do not establish the same initial cause. #51316 attributes the first collision to concurrent assignment. This report deterministically isolates a durable post-condition: an aggregate already has an event head higher than its persisted event_sequence cursor. A later publish derives an already-used sequence; rollback leaves that cursor unchanged, so every retry collides again.\n\nThat durable mismatch could plausibly be left behind after a concurrent collision, but it can also be introduced by historical shared-database/cross-version scenarios. PR #51413 reconciles the cursor with the actual event head in the same transaction before allocating the next sequence. It does not replace correct concurrent allocation, but it makes either persisted stale-cursor state recoverable.\n\nI will defer to maintainers on whether #51411 should be treated as a duplicate, related report, or the recovery-focused follow-up to #51316.
4. ImBIOS commented on Oct 4, 2026

   

   ImBIOS

   on Oct 4, 2026

   Contributor

   More actions

   Hit this in the wild without any manual fixture edits — the desync developed during normal streaming.

   Evidence from the live DB (binary v2.0.22, Linux x64, WAL mode, 9.6G shared opencode.db):

   • One session: 687 contiguous events (seq 42–728), but event_sequence.seq stuck at 691. Next publish tried seq 692 → UNIQUE constraint failed: event.aggregate_id, event.seq → whole drain aborted (prompt_async failed), session permanently unwritable; every retry collides on the same seq.
   • Only 1 of 1089 aggregates in event_sequence was affected.
   • Reverse direction also observed: after the crash, a failed retry drain advanced event_sequence 728 → 1118 with zero new events committed (max stayed 728). So the counter is decoupled from committed events in both directions, not just behind.
   • Topology note: 3 server processes share this DB (two T3-managed opencode serve on 127.0.0.1, the second spawned right after the crash, plus a pre-existing opencode serve --service). Possibly related to session: two server processes sharing one opencode.db allocate session_message.seq independently - UNIQUE(seq) collisions fail sessions #53146.

   Workaround used: manual UPDATE event_sequence SET seq=(SELECT max(seq)...). This supports the in-transaction high-water-mark recovery suggested in the issue description — deriving the next seq from both tables would have self-healed both directions here.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the precise report and steps.

   I couldn't reproduce this on v2 (@opencode/cli@2.2.0, the latest release). Here's what I did:

   1. Sent a prompt in a new session. event_sequence.seq for the session was 6.
   2. Lowered only that cursor by 2, leaving everything else alone.
   3. Sent two more prompts. Both went through with no UNIQUE constraint failed: event.aggregate_id, event.seq error, and the cursor carried on from 4.

   On v2 a stale cursor can't cause this collision. The local CLI and service never write rows to the event table: the write is behind a persist option that defaults to off in packages/core/src/bus.ts, and only the workerd server turns it on. So there is nothing for event_sequence.seq + 1 to collide with. The same logic is in v2.0.32, v2.1.0 and current dev (86ce19d).

   The failure you describe comes from v1 (opencode-ai 1.x, including 1.18.32), which does write event rows. The v2 reports of the same error came from a v1 or desktop 1.x process sharing one opencode.db with v2, as in #42260. Current v2 keeps its data in a separate opencode-next.db. v1 only receives fixes for critical bugs, so a recovery step there is unlikely.

   Related issues:

   • Shared-service event_sequence cursor drifts behind event rows; affected session becomes permanently unappendable (UNIQUE constraint failed: event.aggregate_id, event.seq) #56460 and core: concurrent writers on shared SQLite DB cause UNIQUE constraint failures and permanent event_sequence desync #54464: the same error with v1 and v2 sharing one database
   • core: continuing a V1-created session fails with UNIQUE constraint on event seq #52395: continuing a session created under v1
   • Session permanently bricked by SQLite UNIQUE constraint (event.aggregate_id, event.seq) collision #51316: the earlier 1.18.32 report
   • opencode2 mutates shared V1 database and breaks opencode 1.x coexistence #42260: v2 changing a database shared with v1

   If you can trigger this on v2 alone, with no v1 or desktop 1.x process using the same data directory, please reply with your opencode --version, the database path in use and the steps. We'll look again.
6. opencodejr

   closed this as not plannedon Oct 31, 2026
7. opencodejr commented on Oct 31, 2026

   

   opencodejrBot

   on Oct 31, 2026

   More actions

   We haven't heard back, so I'm closing this as not planned.

   To recap: I couldn't reproduce this on v2 (@opencode/cli@2.2.0). After I lowered a session's event_sequence.seq, the next prompts still went through, because the local v2 app doesn't write rows to the event table. The collision you describe comes from v1 (1.18.32) writing to a database shared with v2. v1 only receives fixes for critical bugs, and current v2 keeps its data in a separate opencode-next.db. Related: #56460, #54464, #52395, #42260.

   If this happens on v2 alone, with no v1 or desktop 1.x process using the same data directory, please open a new issue with your opencode --version, the database path and the steps, and we'll look again. Thanks for the detailed report.