anomalyco / anomalyco/opencode

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

Open
#49,641 2 comments 0 reactions 1 assignee View on GitHub

@kitlangton is already working on this.

Since Sep 18, 2026.

2.0
Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Summary

The V1→V2 session importer (kv.migration.v1-v2) is a one-shot job. Sessions created by OpenCode 1.x after the first V2 launch remain in the legacy session / message / part tables and never appear in V2 session lists.

Environment

  • opencode version: 2.0.7
  • OS: Linux 7.1.8-200.fc44.x86_64 (linux x64) — Fedora 44
  • Terminal: TERM=xterm-256color, COLORTERM=truecolor
  • Shell: /bin/bash
  • Install/channel: latest (opencode v2.0.7)
  • Active plugins: none found in ~/.config/opencode/opencode.jsonc

Reproduction

  1. Install and use OpenCode 1.x long enough to have session history in ~/.local/share/opencode/opencode.db (session / message / part).
  2. Launch OpenCode 2 (beta or 2.0.x) once. Confirm GET /api/experimental/migration/v1 returns {"status":"completed"} and kv.migration.v1-v2 is {"phase":"completed"}.
  3. Continue using OpenCode 1.x (for example 1.18.27 / 1.18.30) in the same data directory. Create new sessions.
  4. Switch back to OpenCode 2.0.x and open the global session list and the project/directory session list for those workspaces.

Expected Behavior

V2 should import any remaining V1 session rows that are not already present in session_v2, including sessions created after the first V2 launch. GET /api/experimental/migration/v1 should not report completed while unmigrated V1 sessions still exist.

Alternatively, mixed V1/V2 use after first V2 start should be documented as unsupported, with a supported way to re-run the importer.

Actual Behavior

The importer ran once on first V2 start and never ran again.

On this machine:

  • First V2 launch: 0.0.0-beta-18999 at 2026-09-04 01:21:50 UTC-4
  • kv.migration.v1-v2 = {"phase":"completed"} at that same timestamp
  • All 36 V1 sessions created before that timestamp exist in both session and session_v2
  • All 7 V1 sessions created after that timestamp exist only in session
  • GET /api/session/{id} for those 7 IDs returns SessionNotFoundError (HTTP 404)
  • GET /api/experimental/migration/v1 still returns {"status":"completed"}

Example missed session (still fully present in legacy tables):

  • id: ses_f82d98a72ffempGkC713ArwcVJ
  • title: Turing-cluster AI workload Terraform plan
  • created 2026-09-07, updated 2026-09-10
  • version: 1.18.27
  • 318 messages / 1,492 parts
  • also has 6,831 rows in event (session.created.1, session.updated.1, message.updated.1, message.part.updated.1)
  • no session_v2 row, no session_message rows

V2 session lists (global and project/directory) therefore omit it.

Additional Context

  • Related: #41217 (closed as completed by #40723). This is a leftover gap: #40723 imported sessions that existed at first V2 start, but the completed KV marker prevents importing V1 sessions written afterwards.
  • The published V1→V2 migration guide does not mention session history.
  • Frequency: consistent. Every post-migration V1 session is missing; every pre-migration V1 session is present.
  • Data is not deleted. Workaround today is reading the legacy SQLite tables directly. There is no user-facing command to re-run the importer.
  • Counts from ~/.local/share/opencode/opencode.db (read-only):
session            43
session_v2         49
message          3032
part            13707
session_message  3240

before first V2 launch: 36 V1 sessions, all in session_v2
after first V2 launch:   7 V1 sessions, none in session_v2

The 7 missed sessions were written by OpenCode 1.18.27 and 1.18.30 while V2 already considered migration complete. Later V2-native sessions (2.0.3–2.0.7) exist only in session_v2, as expected.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.