Repository navigation
chore(core): review V2 table and durable event type names before GA #34922
Description
While V2 is still beta, do one deliberate pass over durable naming — SQL table names, column names, and versioned event types — so code vocabulary and durable vocabulary match before renames become expensive. Needs discussion with Dax before any migrations land.
Known instance
session_context_epochshould likely becomesession_context_checkpoint: refactor(core): simplify system context into a belief model #34917 renamed the module and symbols (SessionContextEpoch→SessionContextCheckpoint) but deliberately left the table name untouched.ALTER TABLE ... RENAME TOis metadata-only in SQLite (no data or field loss), and the repo already uses the pattern.
Things to settle
- Multi-process safety: a rename migration applied by one process breaks other already-running processes still reading the old name. During beta this is probably acceptable (V2 state was recently wiped by reset migrations anyway), but decide the general policy: are durable renames allowed until GA, and is there a cutoff?
- Field-deletion policy: clarify the "never delete fields in a migration" rule vs. history —
20260622142730_simplify_session_context_epochdropped three columns. Was that a pre-release exemption for V2 tables? Write the actual rule down. - Event types: review versioned durable event names (e.g.
session.next.*.1) with the same lens; renaming those is harder than tables since old rows replay through decode.
Scope
One review pass producing either "names are fine" or a single migration batch, before V2 GA.
Activity
opencode-agent commentedon Jul 5, 2026
Consolidated #34832 here. Keep its broader audit checks in scope alongside table/event naming: migration-sensitive records, system-context and synthetic-message replay safety, event versioning, and a documented pre-GA outcome checklist.
Dante-dan commentedon Sep 26, 2026
I checked the current
v2tree for the pre-GA naming pass. The originalsession_context_epoch→session_context_checkpointexample is no longer a live rename: the V2 split migration drops that old table on both upgrade paths. Current context storage usesinstruction_state/instruction_entry(schema).Two durable names still deserve an explicit decision:
session_v2.time_suspendednow stores the execution-claim timestamp; the schema calls it a historical column name. A column rename would affect already-running processes and should follow the chosen migration policy.${type}.${version}and replay rejects unknown durable types. Renaming an event therefore needs an old-version decoder/upcast or an explicit pre-GA reset decision; changing the current definition alone would strand existing rows.For the requested audit outcome, could the V2 maintainers decide whether pre-GA renames and destructive drops are allowed for V2-only state, the cutoff for that exception, and whether mixed-version processes must remain compatible during a migration? That also resolves the apparent tension with the older
simplify_session_context_epochcolumn drops. I have only inspected source here; no migration or runtime validation is claimed.opencodejr commentedon Oct 29, 2026
Thanks for opening this. It's a planning and naming review rather than a bug, so there's nothing to reproduce. Here's what I found when checking the cited facts against the latest
dev(f43563b2f4e0), in case it helps the review:session_context_epochno longer exists ondev. Migration20260804233008_loose_psylockedrops it (DROP TABLE/DROP TABLE IF EXISTS), and no current schema defines it under the old or new name. Thesession_context_checkpointrename may not be needed, unless the table is meant to come back.20260622142730_simplify_session_context_epochdid dropagent,replacement_seqandrevision, and20260622170816_reset_v2_session_statelater wiped the rows. That supports writing down a pre-GA exemption for V2 tables.loose_psylockealso renamessession→session_v2and dropsdata_migrationandsession_input.dev:project,project_directory,instruction_blob,instruction_state,blob,workspace,kv,credential,account,account_state,event_sequence, plus the session, inbox, worktree, permission, schedule and event tables. Those, along with the versioned event types, are what's left to review.neriousy commentedon Nov 12, 2026
Closing this. The one concrete rename it listed,
session_context_epoch→session_context_checkpoint, is no longer needed because migration20260804233008_loose_psylockedrops that table. V2 has also shipped since then, so any further table or event renames now need their own migration and a specific issue.