session: import rejects V1 export JSON; V2 export round-trip works #49314

Activity

1. opencode-agent

   added

   2.0

   on Sep 16, 2026
2. github-actions

   assigned

   jlongster

   on Sep 16, 2026
3. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report. I tried both halves on 2.0.4 and couldn't reproduce the round-trip failure.

   What I tried (Linux, @opencode/[email protected], V1 [email protected], mock OpenAI-compatible model). The model made four tool calls: a shell command that succeeds with no output, one that exits non-zero, a read of a missing file (error) and a call to a tool that doesn't exist (error).

   • A native V2 session: opencode session export <id> followed by opencode session import into a fresh database imported fine.
   • A session created in V1 1.18.31, migrated by V2, then exported and re-imported: also fine.

   Completed tool parts not having error is expected: the schema requires error only on status: "error" parts, and there content is optional. Because the importer matches each tool part by its status, a Missing key [...]["state"]["error"] message most likely means one part didn't fit the schema at all, for example a completed tool with an empty content array, and the error points at the wrong field. Adding error everywhere and then hitting a missing content[0] fits that.

   V1 opencode export JSON: I do get Missing key ["info"]["location"], on 2.0.4 and on current dev. But session import has no code that converts V1's export format (info.directory, V1 parts); it only reads V2's own format. That part works as designed and would be better tracked as a feature request (importing V1 exports), alongside the migration gaps in #50130 and #41217.

   What would help with the round-trip failure:

   • A sanitized export of a session whose own export fails to import: opencode session export <id> --sanitize > v2.json (it redacts text and file data). Please check it before attaching.
   • Alternatively, just the JSON of one or two tool parts named in the error (e.g. messages[N].content[M]).
   • Whether that session was created natively in V2, migrated from V1, or imported by your converter.
   • Whether it still happens on the latest release.

   Please reply here with the details, or edit the issue and leave a comment saying you've updated it.
4. ransagy commented on Oct 28, 2026

   

   ransagy

   on Oct 28, 2026

   Author

   More actions

   Retracting the round-trip claim. Tested on 2.2.0, fresh data dir, --standalone:

   • native V2 export → import: OK (70 msgs / 59 tools)
   • converter-built session export → import: OK (1,751 msgs / 1,319 tools)

   Inferred from missing state.error counts; I mistakenly assumed it had been locally tested. No repro.

   V1 export still rejected on 2.2.0: Missing key ["info"]["location"], then Expected Session.Message.Info at ["messages"][0]. By design; not needed here. Can be a feature request if anyone asks — fixture (736 msgs / 2,584 parts) and working mapping available.
5. ransagy

   changed the title [-]session: v2 import rejects V1 export JSON and its own export file (SchemaError missing keys)[/-] [+]session: import rejects V1 export JSON; V2 export round-trip works[/+] on Oct 28, 2026
6. ransagy

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

   

   opencodejrBot

   on Oct 31, 2026

   Contributor

   More actions

   Closing this for now, since we haven't heard back. On 2.0.4, I exported and re-imported both native V2 sessions and sessions migrated from V1. Those sessions included completed, failed and invalid tool calls, and every import succeeded, so I couldn't reproduce the round-trip failure. To find the cause we need the tool part that fails to import.

   If it still happens, please reopen or comment with a sanitized export of the failing session (opencode session export <id> --sanitize, checked before you attach it) or the JSON of the tool part named in the error. It also helps to say whether that session was native, migrated from V1, or created by your converter.

   session import can't read V1's opencode export JSON because nothing in the import path converts that format. A feature request for that, alongside #50130 and #41217, is welcome. Thanks for the detailed report.