`bos db repair --mode history-reset` drops the shared journal for every workspace and re-applies migrations into `public`

Abierto
  • ¿Algo no está bien?
#664 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
postgresql, typescript
Área
backend, database

Línea de trabajo

Start with services/db/repair.ts, then read db/core.ts and the workspace drizzle.config.ts files to confirm how the shared journal and schema are selected. Compare the repair path with runMigrations and its search path handling. Done means repair preserves other workspaces' migration history and applies or safely refuses migrations for the target workspace schema.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Environment

everything-dev 2.0.0-rc.27

Where

services/db/repair.ts:

  1. Journal reset is not slug-scoped — `dist/services/db/repair.mjs:60`:
    ```ts
    await pool.query(`DROP TABLE IF EXISTS ${journalRef}`);
    ```
    The journal table is shared by all workspaces on one database (`getMigrationStorage` default; `PER_PLUGIN_ISOLATION = false` in `db/core.ts`), so "reset the migration history" for plugin A silently wipes the recorded history of every other plugin and the api workspace on that database.

  2. Reapply targets the wrong schema — the fix path re-runs drizzle-kit migrate via each workspace's `drizzle.config.ts`. That config maps the journal schema/table but has no notion of the v2 data schema, so drizzle-kit creates/validates tables in the session `search_path` (`public`). The v2 runtime (`runMigrations`) scopes plugin tables into `plugin_` (it even strips `"public".` prefixes from migration SQL and runs under `search_path="plugin_,public"`).

Consequences (observed on nearbuilders.org during a v1→v2 consolidation)

  • On a v1 per-plugin DB that boots with `drift-safe-repair` (runtime checks `plugin_`, finds journal hashes + tables in `public` only): repair cannot fix the boot — the runtime error persists, and repair may instead recreate tables in `public`.
  • On a healthy consolidated database: repair destroys every workspace's journal and can spray `public`-schema copies of plugin tables.

Suggested fix

  • Make the journal operation slug-scoped under the shared-journal topology: delete only the target workspace's migration hashes (the history rows whose hashes the workspace's local migrations reference).
  • Re-apply migrations under the workspace's data schema (`search_path = plugin_,public`), matching what the runtime runner does — or reuse `runMigrations` directly.
  • Alternatively: refuse to run against the shared-journal topology and point users at re-baseline/consolidation tooling.

Note: because the runtime runner is drift-tolerant (the tables-present preflight records migration hashes as applied without replaying DDL), an actual journal-only reset usually self-heals on next boot when tables exist in the right schema — a `public`-targeted drizzle-kit pass adds risk without fixing anything.

Lenguaje dominante
TypeScript
Estrellas
5
Forks
3
Merge medio
9 h 16 min
PR fusionados (30 d)
160

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NEARBuilders/everything-dev

Todos los issues de NEARBuilders/everything-dev

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.