migration: V1 1.19.4 sessions not migrated to session_v2 #59517

Summary

Upgrading from OpenCode V1 1.19.4 to V2.1.4 silently left 15 sessions invisible. Their rows are still present in the legacy session, message, and part tables, but no corresponding rows were written to session_v2, so the session list, session picker, and session export cannot see them. Every affected session was created by V1 1.19.4; all 211 sessions from earlier V1 versions migrated correctly.

Environment

• opencode version: 2.1.4 (upgraded from 1.19.4)
• OS: Windows 11 Home, Microsoft Windows NT 10.0.26200.0
• Terminal: TERM=xterm-256color (no TERM_PROGRAM / COLORTERM)
• Shell: C:\Windows\system32\cmd.exe (invoked from PowerShell)
• Install/channel: latest (npm global install, @opencode/cli 2.1.4)
• Active plugins: none (only $schema in ~/.config/opencode/opencode.jsonc)

Reproduction

1. Using OpenCode V1 1.19.4, create sessions in several different project directories.
2. Upgrade to OpenCode 2.1.4 and start the app so the V1->V2 migration runs.
3. Run opencode session list or open the session picker for an affected directory.
4. The affected sessions are absent. opencode session export <session-id> returns Session not found: <id>.

Expected Behavior

All V1 sessions are migrated into session_v2 and visible in the session list, with their messages and tool output intact.

Actual Behavior

15 sessions remain only in the legacy tables and are unreachable through V2's read paths.

Read-only queries against opencode.db before recovery:

select count(*) from session where id not in (select id from session_v2);
-- 15

Correlation:

• All 15 affected rows have session.version = '1.19.4'.
• All 211 rows with earlier versions (1.15.x through 1.18.x) have matching session_v2 rows.
• The affected sessions were spread across four different directories and five project_id values (including global), so directory/project does not appear to be the discriminator.
• storage/migration contains 2; the migration appears to have completed without reporting an error.
• Message and part data is fully intact. Example: one affected session had 192 message rows, 739 part rows, 214 tool calls, and 2 inline image attachments.

There is no warning or log entry indicating sessions were skipped.

Additional Context

Workaround used: build a projected transcript from the legacy session / message / part rows and re-import it through POST /api/experimental/session/import. Importing with the original info.id preserves the session ID, and parent sessions are imported before children. All 15 sessions were recovered this way and round-trip correctly through session export (verified message counts, tool counts, and attachment sizes).

One gotcha when replaying tool calls through import: the stored tool item's executed flag means "executed by the provider", not "has a result". Setting executed: true for locally executed tools makes the compiler place their results inside the assistant message, and the next prompt fails with OpenAI Chat assistant messages only support text, reasoning, and tool-call content for now before any request is sent. Normal V2 transcripts store executed: false for these items; with that value the restored sessions resume normally. Both errors are hard to diagnose because neither names the offending session or message.

Suggested fix: after the V1->V2 projection pass, compare session against session_v2 and migrate or report any remaining rows, rather than completing silently. A startup warning with the count and IDs would have made this immediately diagnosable.

Related minor observations:

• session export cannot read legacy rows, so the affected sessions returned 404 before recovery.
• session import is strict about required fields; a partial payload fails with an opaque Bad Request (the detailed InvalidRequestError message is only visible when calling the API directly).