fusion/.changeset/pg-boot-no-sqlite-touch.md at bc348345a469e07cb4e2cd008a87fddbb725e79a

Files

gsxdsm fbcd00204a fix: snake_case legacy SQLite table names in the PG migrator and keep PG-mode boots from touching SQLite

Two post-cutover fixes:

1. The SQLite -> PostgreSQL migrator matched table names verbatim while only
   column names were snake_cased, so all 22 legacy camelCase tables
   (activityLog, runAuditEvents, mergeQueue, taskClaims,
   projectNodePathMappings, ...) resolved zero PostgreSQL columns and were
   silently skipped as 'no PostgreSQL counterpart'. First observed as
   'Project/node path mapping not found' on engine start because
   central.project_node_path_mappings was never populated. TablePlan now
   carries a snake_cased pgTable used for every PostgreSQL-side operation;
   regression test migrates a camelCase activityLog into project.activity_log.

2. The first-boot auto-migration guard opened .fusion/fusion.db with a
   read-write DatabaseSync on every boot (isValidSqliteDatabaseFile), which
   performs WAL recovery + checkpoint — writing the legacy file on each PG
   boot. The PG emptiness count now runs before the SQLite probe, so
   steady-state PG boots never open the legacy SQLite files at all.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-13 20:30:41 -07:00

511 B

Raw Blame History

@runfusion/fusion

@runfusion/fusion
patch

summary: Stop PostgreSQL-mode boots from opening and checkpointing the legacy SQLite files. category: fix dev: The first-boot auto-migration guard probed .fusion/fusion.db with a read-write DatabaseSync open on every boot, performing WAL recovery + checkpoint (file writes). The PostgreSQL emptiness count now runs first; the SQLite probe only runs on the empty-PG path where auto-migration is actually considered, so steady-state PG boots leave the legacy files byte-quiet.

511 B Raw Blame History

511 B

Raw Blame History