session: V1→V2 importer skips sessions created after first V2 launch #49641

Activity

1. github-actions

   assigned

   kitlangton

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

   

   github-actionsBot

   on Sep 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • server: pre-update sessions missing from session list after update to v2.0.5 #49412: Same root cause — V1 sessions written after a one-shot migration stamp are missing from V2 session lists; the migration was triggered during an earlier V2 beta/trial run against the same data directory.
   • Mixed stable/beta channels sharing one data dir silently split sessions across session and session_v2 #44028: Same underlying mechanism — mixed stable/beta channels sharing one data dir cause the one-shot kv.migration.v1-v2 stamp to mark migration complete while V1 continues creating sessions that never reach session_v2.
3. opencode-agent

   added

   2.0

   on Sep 18, 2026
4. drsmile1001 commented on Sep 19, 2026

   

   drsmile1001

   on Sep 19, 2026

   More actions

   Three details not covered here or in #49412 / #44028. The first matters most, because the obvious workaround destroys data.

   Resetting the KV marker destroys the event log

   Deleting kv.migration.v1-v2 to force a re-run is not safe. From a cleared state the importer deletes the entire event table before it copies anything.

   Where V1 kept running after the marker was set, every row in event belongs to the sessions that are still missing: V1 persists a durable event per message and part, while V2's CLI path persists none. Resetting the marker therefore wipes the event log of exactly the sessions being recovered.

   event_sequence must not be lowered to the projection watermark

   The importer upserts event_sequence.seq to transformSession's watermark, which is only safe because it has already emptied event.

   For an aggregate whose events survive, event has a unique index on (aggregate_id, seq) and new events publish at latest + 1, so lowering the sequence makes the next publish collide with an existing row. Keeping the original value avoids this; the only cost is a gap in session_message.seq, harmless because the projector and the bus order by seq rather than assume contiguity. An incremental importer would need to handle this rather than reuse the current upsert.

   The status endpoint reports completed while sessions are missing

   GET /api/experimental/migration/v1 answers from the KV marker alone and never compares session against session_v2, so anything built on it reports a healthy migration. Returning required whenever the difference is non-empty would be a cheap fix.

   Suggested direction

   Drive the import from the set difference rather than a completion marker, drop the unconditional event wipe, and leave event_sequence alone for aggregates that still have events. That also makes the job re-entrant, which the mixed V1/V2 window requires.

   Workaround

   transformSession from @opencode/core/database/v1-migration.bun is exported as a pure function, so the missing sessions can be recovered out-of-band: copy the set difference into session_v2 and rebuild session_message from message and part through it, leaving event, event_sequence and the marker untouched. Run under bun, since the node condition resolves to a noop build. Snapshot with .backup and stop the service before writing.

   Environment

   • opencode 2.0.8, installed with the official curl install script
   • Fedora Linux 44, x86_64
5. edyfox commented on Sep 24, 2026

   

   edyfox

   on Sep 24, 2026

   More actions

   Confirmed independently on a different platform, with a working non-destructive
   recovery path — neither of which I found in the existing reports.

   Environment: Android / Termux + proot Debian, opencode 2.0.15, single shared
   ~/.local/share/opencode/opencode.db. Same failure: 78 V1 sessions created after
   an earlier V2-beta trial were absent from the V2 view. All present in the legacy
   session table with full message/part transcripts.

   Root cause confirmed at the code level (bundled migration in the 2.0.15 binary):
   the event table is purged only when the kv.migration.v1-v2 row is absent
   (u === void 0). With the row present as {"phase":"sessions"}, the import re-runs
   and the purge is skipped. So a sticky {"phase":"completed"} marker is precisely
   what strands V1 sessions written after it.

   Safe recovery (verified, zero data loss):

   1. Back up the DB first (SQLite online backup API — safe while the server runs).
   2. Reset the marker — do not delete it:

      INSERT INTO kv (key,value,time_created,time_updated)
      VALUES ('migration.v1-v2','{"phase":"sessions"}', <now_ms>, <now_ms>)
      ON CONFLICT(key) DO UPDATE SET value=excluded.value, time_updated=excluded.time_updated;

      Deleting the row instead triggers the destructive event purge. Reset, never
      delete.
   3. Trigger the migration without killing the live session: start a throwaway
      opencode serve on another port against the same DB, wait for the marker to
      return to completed, then stop it.

   Result: session 156 → session_v2 158 (156 V1 + 2 native V2), 0 missing,
   0 duplicate ids across session_v2 / session_message / part, event intact
   at 65,781 rows.

   Same root cause reported in #44028 and #49412.

   Suggested fix direction: make the importer idempotent — re-run while
   count(session) > count(session_v2 ∩ session) — and/or report completed from
   GET /api/experimental/migration/v1 only when no unmigrated V1 rows remain. The
   marker-reset procedure above would also make a good documented repair path.
6. neriousy commented on Oct 20, 2026

   

   neriousy

   on Oct 20, 2026

   Member

   More actions

   Thanks for the detailed timeline and the warning about deleting the migration marker — this is the same problem as #50130, where we're tracking V1 sessions created after the first migration. Please subscribe or add a 👍 there, and feel free to add any further recovery details so they stay together.
7. neriousy

   closed this as a duplicateof server: V1 sessions created after migration.v1-v2 completes are never imported #50130 on Oct 20, 2026