jake/Lumotia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(rb-02): migrations run inside a single transaction

Browse Source 
Every multi-statement migration and its matching schema_version insert
now execute on the same sqlx Transaction. A failure anywhere — a bad
statement, the version insert, or the commit itself — rolls the
database back to its previous state, so the next startup replays the
migration against a clean schema rather than a half-mutated one.

Extracted run_migrations_slice(pool, migrations) as the single apply
path. run_migrations delegates to it with MIGRATIONS; the test helper
run_migrations_up_to now filters MIGRATIONS by target and delegates to
the same code, eliminating the duplicated loop that previously lived
in the test module.

Regression test multi_statement_migration_rolls_back_on_failure
injects a poisoned v9 migration (valid CREATE followed by a bogus
function call) and asserts neither the partial schema change nor the
schema_version row persists after the failure.

SQLite DDL participates in transactions, so this is sufficient. Any
future migration that needs an implicitly-committing statement
(VACUUM / REINDEX / ATTACH — none today) must be its own
non-transactional migration; that's a reviewer responsibility.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jake
2026-04-22 10:27:29 +01:00
parent b48d39bfb1
commit 05d823bf05
3 changed files with 135 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
docs/issues/c3-migrations-atomicity.md
View File

@@ -4,6 +4,32 @@
**Path:** `crates/storage/src/migrations.rs:263-299`
**Source:** [2026-04-22 code review](../code-review-2026-04-22.md#c3--multi-statement-migrations-can-half-apply)
**Labels:** release-blocker, critical, data-integrity, storage
**Status:** RESOLVED (2026-04-22)
## Resolution
Extracted `run_migrations_slice(pool, migrations)` as the single code
path that applies pending migrations. For each pending version it
opens a `Transaction` via `pool.begin()`, applies every split statement
on that transaction, records the `schema_version` row inside the same
transaction, and finally `tx.commit()`s. A failure anywhere in the
sequence — statement, version insert, commit — rolls the whole
migration back.
`run_migrations` delegates to `run_migrations_slice(pool, MIGRATIONS)`
and the test helper `run_migrations_up_to` to a filtered subset, so
only one version of the apply logic exists.
Regression test `multi_statement_migration_rolls_back_on_failure`
feeds a poisoned v9 migration (`CREATE TABLE poison_marker; SELECT
this_function_does_not_exist()`) through `run_migrations_slice`. The
call returns `Err`, and post-call `SELECT COUNT(*) FROM poison_marker`
fails with "no such table" while `MAX(schema_version)` remains at 8.
SQLite DDL participates in transactions, so this is sufficient for the
Kon schema. If any future migration needs a statement that implicitly
commits (`VACUUM`, `REINDEX`, `ATTACH`) — none do today — it must be
split into its own non-transactional migration. Reviewer's job to flag.
## Problem