V1→V2 migration loses/hides history: corrupt-part migrator 500s, undecodable rows report no field detail, >9k-message imports 500 with empty body, project picker is a hidden shortcut #42671

Activity

1. github-actions

   assigned

   jlongster

   on Aug 15, 2026
2. github-actions commented on Aug 15, 2026

   

   github-actionsBot

   on Aug 15, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of (or closely related to) existing issues. Please check:

   • V1→V2 session migration fails when previous channel DB lacks fork_boundary #41341: V1→V2 session migration fails when previous channel DB lacks fork_boundary — the migrator 500ing on corrupt/incompatible legacy rows is the same subsystem and failure mode described here.
   • mod+shift+w and mod+o do nothing in the new layout #39785: mod+shift+w and mod+o do nothing in the new layout — the project/directory picker keybind being non-functional in the new layout is covered there; this report's mod+shift+o (project.select) issue is likely the same root cause.

   For keybind-related issues, please also check our pinned keybinds documentation: #4997
3. opencode-agent

   added

   2.0

   on Aug 15, 2026
4. Qiiks commented on Aug 20, 2026

   

   Qiiks

   on Aug 20, 2026

   More actions

   Independent reproduction with a corrected decode harness (2026-08-20, fork 1.18.18 / v1.18.18 serve)

   Reproduced the same decode failure class from step 4 on a fork binary (1.18.18, opencode serve --port 4096) against a long-lived dual-layer DB. Evidence below is from the serve's own logs plus a bun:sqlite enumeration that mirrors the server-side decoder exactly.

   1. The decode failure is DB-wide on session_message, not one corrupt session

   Harness calibrated to the server's decode path (packages/core/src/session/history.ts → SessionHistory.load), with id and sessionID injected from SQL columns exactly as the server does:

   • 52,575 of 58,002 session_message rows fail decode under the current SessionMessage.Message schema
   • The failures are the same V1-shaped row class described here: legacy {"type":"aborted"} error objects (pre-tighten error union), rows missing required fields added after they were written (parentID, path, mode, agent, cost, tokens, reasoning-part time.start), and rows carrying role:"synthetic" that the current schema no longer accepts as a standalone role
   • Live endpoint confirmation: GET /api/session/:id/message → 500 "failed to decode session message" for every affected session; serve log shows the rejection at [N]["info"]["error"]

   2. Stronger finding: the projector stopped writing session_message entirely (Aug 13)

   Fresh sessions created after the V1/V2 split merge have zero session_message rows — SessionProjector (packages/core/src/session/projector.ts) no longer projects that table. So this isn't just "old rows are undecodable": the V2 message table is write-dead for new sessions and read-dead for old ones. The table is currently a zombie: 58,002 rows, ~90% undecodable, no new writes.

   3. Why it's invisible today — and the trigger that makes it user-visible

   The app's detectServerProtocol (packages/app/src/utils/server-protocol.ts:24-34) returns "v1" for any healthy server (/global/health → healthy:true short-circuits before the v2 probe). All current clients (web UI, mobile SDK, paseo SDK 1.14.46) therefore ride the legacy /session/:id/message surface and never touch the V2 read path — which is why nothing crashes until a V2-protocol client connects. The moment protocol detection or a client selects v2, every old session with pre-merge rows 500s, exactly as step 4 predicts.

   4. The legacy surface has the same row class — fixed at the data layer, already verified

   The same V1-shaped rows also break the legacy unlimited fetch (validates every row against SessionV1.WithParts), which is the surface mobile/paseo/web actually use. That side was repaired in-place on 2026-08-20 (no fork changes, no migration):

   • 13 legacy rows {"type":"aborted"} → current writer's {"name":"MessageAbortedError","data":{"message":"Aborted"}} (shape verified against 3 post-merge reference rows the 1.18.18 binary itself emits)
   • 1,493 assistant rows: backfilled parentID (most-recent preceding user message) and path {cwd,root} from per-session healthy values
   • 13 role:"synthetic" rows → reparented as synthetic:true text parts onto the preceding user message (matches current writer via reminders.ts; 0 post-merge standalone rows exist)
   • 1,333 reasoning parts time:{created,completed} → time:{start,end}

   Result: 13,053 messages + 41,648 parts decode clean (0 failures), both affected sessions return HTTP 200 on unlimited fetch, and the serve reads the DB live per request (no restart required). The repair surface was precisely bounded — 1,506 failing rows across exactly the 2 user-visible sessions, matching the serve log's rejection indexes.

   Suggested fix direction for the V2 side

   Data-level repair of session_message is impractical at this scale (52.5K rows) and pointless while the projector is write-dead. The two fork-side options, per this issue's framing:

   1. Decoder tolerance — map the known legacy shapes at decode time ({"type":"aborted"} → MessageAbortedError, tolerate missing optional fields with schema defaults). This kills the whole breakage class without a data migration, but is a carve-out from the deliberate schema tighten.
   2. Restore the projector — investigate why the merged tree stopped writing session_message (upstream may have disabled/renamed the projection); without writes, V2 message history is empty for all new sessions regardless of decode.

   Both are latent today (no client selects v2), but become user-visible the moment the V1 cutover (#35054) lands. Happy to provide the harness script, per-session row dumps, or the exact failing-row enumeration if useful.
5. github-actions commented on Oct 20, 2026

   

   github-actionsBot

   on Oct 20, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
6. github-actions

   closed this as not plannedon Oct 20, 2026