Jake
592b894790
Captures the 12 items from docs/code-review-2026-04-22.md that must land before v0.1 ships. One markdown file per issue with: severity, path:line, problem description, acceptance criteria, fix scope, and dependency graph. Split by severity: - 3 CRITICAL: live-session race, migration atomicity, transcript- profile FK - 9 MAJOR: monolith refactor, channel-fatality, capture worker join, runtime capabilities, macOS App Nap, decoder error prop, LLM prompt preflight, keystore thread-safety, hotkey device filter README.md indexes them with a fix-order dependency graph and a fish-shell script for bulk-converting to GitHub issues once `gh` CLI is installed and authed. Deferred step by user decision — markdown tracker is authoritative until then.
25 lines
1.6 KiB
Markdown
25 lines
1.6 KiB
Markdown
# RB-02 CRITICAL: multi-statement migrations can half-apply
|
|
|
|
**Severity:** CRITICAL
|
|
**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
|
|
|
|
## Problem
|
|
|
|
`run_migrations` executes each statement individually and only records the schema version after the full migration succeeds. If a multi-statement migration (v5, v6, v8 — any containing more than one `CREATE` / `ALTER` / `UPDATE`) fails mid-run, or the process is killed between statements, the schema can end up partially changed while still appearing unapplied. The next startup replays the same migration against the mutated database, which can fail in confusing ways or corrupt data further.
|
|
|
|
## Acceptance
|
|
|
|
- Every migration runs inside a single `BEGIN` / `COMMIT` transaction.
|
|
- The version row update happens inside the same transaction — atomic success or no change.
|
|
- Regression test: a migration that panics partway through leaves the database at the previous schema version with no partial changes visible on restart.
|
|
|
|
## Fix scope
|
|
|
|
Medium. Wrap each migration in `pool.begin()` / `tx.commit()`. The version update and the migration statements all execute on the same `Transaction` handle. Needs careful review of any migration that uses implicit commits (SQLite `VACUUM`, `REINDEX`, `ATTACH` — none of which Kon currently uses, but the review pattern should guard against future additions).
|
|
|
|
## Dependencies
|
|
|
|
- Coupled with RB-03 (any v9 migration adding the transcript-profile FK must itself be transactional — this fix is a prerequisite).
|