Downgrade v2 → 1.19.0 also breaks: "no such column: project_id" on migrated DB makes all v1 sessions return 500 (still in release, not just dev) #55555

Descripción

Migrar de 1.19.0 → 2.0.29 (channel latest) y luego volver a 1.19.0 deja la base de datos en un estado híbrido del que la 1.19 no se recupera: todas las sesiones existentes devuelven HTTP 500 Unexpected server error. Check server logs for details. al abrirlas.

Entorno: Linux, bun 1.4.2, opencode serve --service.

Qué hace la v2 que rompe el downgrade

Diff de esquema entre una DB recién creada por 1.19 y la DB tras migrar con la v2 2.0.29:

1. La v2 reescribió la tabla workspace con un esquema reducido, eliminando columnas que usa la 1.19:

   Esperado por 1.19	Tras migrar con v2
   id, type, name, branch, directory, extra, project_id, time_used	id, provider, binding, created_at, last_used_at

2. Faltan 3 tablas que la 1.19 espera: data_migration, session_context_epoch, session_input.

3. La DB queda con ambos esquemas conviviendo: session/message/part (v1) + session_v2/session_message/event/event_sequence/session_inbox/session_pending/instruction_*/kv/__drizzle_migrations (v2).

Error que ve el usuario

• GET /session (listado) funciona.
• GET /session/:id y GET /session/:id/message → HTTP 500 para TODAS las sesiones viejas (no es un problema de una sesión específica).

Log del servidor 1.19 tras el downgrade:

level=ERROR message=failed error="SQLiteError: no such column: project_id"
  at Project.migrateProjectId
  at Project.fromDirectory
  at InstanceStore.boot
  at InstanceStore.load
  at Server.listen

Causa raíz

Project.migrateProjectId (que corre cada vez que se resuelve un proyecto desde un directorio) ejecuta:

db.delete(workspace).where(eq(workspace.project_id, previousId))
db.update(workspace).set({ project_id: newId }).where(eq(workspace.project_id, previousId))

Como la v2 borró workspace.project_id, SQLite falla en prepare() con no such column: project_id, la excepción marca la petición como fallida y el endpoint responde 500.

Verificado dos veces:

1. Tras el downgrade real.
2. Reproducido de forma aislada con opencode serve de 1.19 contra la DB migrada.

Workaround aplicado

Restaurar solo lo que elimina la v2 (cambios aditivos, no destructivos):

CREATE TABLE data_migration (name TEXT PRIMARY KEY, time_completed INTEGER NOT NULL);
CREATE TABLE session_context_epoch (session_id TEXT PRIMARY KEY, baseline TEXT NOT NULL, snapshot TEXT NOT NULL, baseline_seq INTEGER NOT NULL, FOREIGN KEY (session_id) REFERENCES session(id) ON DELETE CASCADE);
CREATE TABLE session_input (id TEXT PRIMARY KEY, session_id TEXT NOT NULL, prompt TEXT NOT NULL, delivery TEXT NOT NULL, admitted_seq INTEGER NOT NULL, promoted_seq INTEGER, time_created INTEGER NOT NULL, FOREIGN KEY (session_id) REFERENCES session(id) ON DELETE CASCADE);
-- + los 3 índices de session_input

ALTER TABLE workspace ADD COLUMN type TEXT NOT NULL DEFAULT 'local';
ALTER TABLE workspace ADD COLUMN name TEXT NOT NULL DEFAULT '';
ALTER TABLE workspace ADD COLUMN branch TEXT;
ALTER TABLE workspace ADD COLUMN directory TEXT;
ALTER TABLE workspace ADD COLUMN extra TEXT;
ALTER TABLE workspace ADD COLUMN project_id TEXT NOT NULL DEFAULT '';
ALTER TABLE workspace ADD COLUMN time_used INTEGER NOT NULL DEFAULT 0;

Con eso, GET /session/:id vuelve a responder 200 y los mensajes cargan completos.

Sugerencias

1. La v2 no debería reescribir/borrar columnas de tablas compartidas con la v1 (o debería hacerlo de forma reversible).
2. Idealmente que el downgrade sea soportado, o al menos que la TUI avise antes de actualizar a la v2 si hay sesiones v1 sin migrar de vuelta.
3. La migración queda marcada como {"phase":"completed"} en la tabla kv (migration.v1-v2), lo que impide reintentarla: no queda forma de "rehacer" la migración desde la UI.

Relacionados

• Desktop fails to load sessions: no such column: project_id #42170 — mismo fallo exacto (no such column: project_id desde Project.migrateProjectId con la tabla workspace sin esa columna) reportado para Desktop 1.18.17; este reporte confirma que sigue ocurriendo en la release 1.19.0 del CLI, y tras un ciclo upgrade→downgrade de la v2 2.0.29.
• server: V1 migration fails every startup with SQLiteError: no such column: path #54009 — la dirección inversa (upgrade v1→v2) falla análogamente con no such column: path, con la misma estructura: esquema mixto + migración que no tolera columnas ausentes.
• fix(core): tolerate missing columns on legacy v1 session table #54013 — PR que tolera columnas faltantes en la migración v1→v2; el mismo enfoque (tolerar esquemas mixtos en vez de asumir columnas) sería el fix correcto para migrateProjectId.