Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#664 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
postgresql, typescript
領域
backend, database

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
5
フォーク
3
平均マージ
9時間 37分
マージ済み PR（30日）
157

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NEARBuilders/everything-dev のほかの issue

NEARBuilders/everything-dev の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。