Description
PR #30785 merged yesterday includes a migration that runs DELETE FROM event and UPDATE session SET workspace_id = NULL unconditionally. I hit this when I synced to dev today.
After digging deeper, the actual impact is more nuanced than my initial report — worth updating.
What the migration actually does
DELETE FROM session_input — derived data, fineDELETE FROM session_message — V2 projection layer, also fine if it gets re-projectedDELETE FROM event — this is the one I was worried about, but see belowUPDATE session SET workspace_id = NULL — this is the real user-visible problem
What message vs session_message actually are
There are two separate tables: message (12,000+ rows, intact, going back to March) and session_message (the V2 projection). The migration only touched session_message and event — the message table with actual conversation content was never deleted. The data is fine.
The actual bug: /sessions shows nothing
Session.list() in session.ts filters by workspace_id when one is provided. The migration set every session's workspace_id to NULL. So when the TUI calls the session list with a workspaceID, zero rows match — not because sessions are gone, but because the join condition can't match NULL.
The sessions are all there. They're just invisible to any workspace-scoped query.
My read on what's happening
The DELETE FROM event suggests the V2 event schema changed incompatibly with existing rows. The workspace_id = NULL suggests workspace association is being reworked. This looks like an in-progress migration for a feature that isn't fully wired yet — not a data-loss issue, but it does mean dev branch users will see an empty session list after updating until the workspace re-association logic lands.
Steps to reproduce
- Existing OpenCode installation with session history
- Update to a build containing
20260604172448_event_sourced_session_input
- Launch OpenCode — migration runs automatically
- Open
/sessions — empty, even though SELECT COUNT(*) FROM session returns 352
OpenCode version
Latest dev (post #30785)
Operating System
macOS 15.x
Terminal
Ghostty
Description
PR #30785 merged yesterday includes a migration that runs
DELETE FROM eventandUPDATE session SET workspace_id = NULLunconditionally. I hit this when I synced todevtoday.After digging deeper, the actual impact is more nuanced than my initial report — worth updating.
What the migration actually does
DELETE FROM session_input— derived data, fineDELETE FROM session_message— V2 projection layer, also fine if it gets re-projectedDELETE FROM event— this is the one I was worried about, but see belowUPDATE session SET workspace_id = NULL— this is the real user-visible problemWhat
messagevssession_messageactually areThere are two separate tables:
message(12,000+ rows, intact, going back to March) andsession_message(the V2 projection). The migration only touchedsession_messageandevent— themessagetable with actual conversation content was never deleted. The data is fine.The actual bug:
/sessionsshows nothingSession.list()insession.tsfilters byworkspace_idwhen one is provided. The migration set every session'sworkspace_idto NULL. So when the TUI calls the session list with a workspaceID, zero rows match — not because sessions are gone, but because the join condition can't match NULL.The sessions are all there. They're just invisible to any workspace-scoped query.
My read on what's happening
The
DELETE FROM eventsuggests the V2 event schema changed incompatibly with existing rows. Theworkspace_id = NULLsuggests workspace association is being reworked. This looks like an in-progress migration for a feature that isn't fully wired yet — not a data-loss issue, but it does meandevbranch users will see an empty session list after updating until the workspace re-association logic lands.Steps to reproduce
20260604172448_event_sourced_session_input/sessions— empty, even thoughSELECT COUNT(*) FROM sessionreturns 352OpenCode version
Latest
dev(post #30785)Operating System
macOS 15.x
Terminal
Ghostty