Repository navigation
fix(doctor): report every migration history serve would refuse - #144
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: cab75e787f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
doctor compared only migration versions, so a changed checksum or a migration recorded as failed read "ok" while serve refused to start. One storage function now judges an applied history the way startup does (a version this build does not know, a row recorded as unfinished, a checksum that differs from this build's), in sqlx 0.9's order, and doctor reports each refusal as a fail naming the version and what to do, read-only as ADR 0016 requires. Startup's own newer-database check reads through the same function, so the wording is defined once. doctor_migrations runs the real binary: for each condition doctor fails and serve refuses the same database, with an intact database as the positive control; doctor_read_only proves the database and its sidecars stay byte-identical while doctor reports a changed checksum. Closes #138 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
doctor now matches serve in both directions: a refusal is a fail, while pending migrations and a database with no migration history yet are a warning that says what the service does on its next start (take a validated backup, then migrate), so running doctor between installing a new version and restarting no longer exits non-zero. Parity tests run the real binary: one migration behind warns, serve starts, takes the pre-migration backup, and doctor then reports ok. Review follow-ups: the Changed and Unfinished messages say what is known and where to go (docs/install.md, Upgrading); the read-only-directory test claims what it proves; the ordering comment is accurate; a timed-out serve is reaped; the operations guide says only named-migration lines mean the service will refuse. Refs #138 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ord ADR 0029 A database that holds tables but has no migration history (the table dropped or emptied) now reads as a refusal: doctor fails and startup refuses it before sqlx tries migration 1 over the existing tables, both through the same storage judgment (MissingHistory). Only a pristine database, with no schema objects of its own, keeps the "no migration history yet" warning. Parity tests run the real binary for the dropped and emptied cases and for the pristine empty-table case. ADR 0029 records the verdict contract operators and monitoring read from doctor's exit status: fail means serve will refuse, warn means the service acts on its next start, ok means nothing is pending or refused. ADR 0016 and the task index link it. Refs #138 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
cab75e7 to
8d403e5
Compare
|
Rebased onto Local full proof on
The earlier receipt for |
A minor release under ADR 0022: the complete installation export (#130), the web stack on SvelteKit 3 and Vite 8 (#140) with the browser floor it brings (Chrome/Edge 111, Firefox 114, Safari 16.4), Rust 1.99 and SQLite 3.51 (#139), and doctor's migration verdict matching serve (#144, ADR 0029). Upgrading from 0.2.0 runs no migration. Versions agree across Cargo and web (tests/release_version.rs); the changelog, README, roadmap, and install guide name 0.3.0. Refs #146 Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Primary Issue
Closes #138
Problem And Outcome
doctorcompared migrations by version only. A database whose stored checksum had changed, or whose migration was recorded as unsuccessful, readok, whileserverefused to start on it:migration 16 was previously applied but has been modified. The reverse mismatch also existed:doctorreportedfailon pending migrations, whichserveapplies by itself, so runningdoctorbetween installing a new version and restarting looked like a failure.After merge,
doctor's migration verdict matchesservein both directions:fail. That covers a version this build does not know, a row recorded as unsuccessful, or a checksum that differs from this build's. The finding names the version and says what to do.warnthat says what the service will do on its next start.Changes
storage.rs: one owning judgment of an applied history,RefusedHistorywith Newer, Unfinished and Changed, plusmigration_history(). The refusal list was derived from sqlx-core 0.9'sMigrator::run_directandvalidate_applied_migrations. Startup's existing newer-database check reads through it, with byte-identical wording.doctor.rs:check_migrationsreports each refusal as afail, and pending or no-history as awarn. It runs SELECTs only, on the existing read-only connection, as ADR 0016 requires. Warnings do not change the exit status; only afaildoes.docs/operations.md(only named-migration lines mean the service refuses),docs/install.md, and a CHANGELOGFixedentry.Scope
Verification
cab75e787f1a4c9d2559dd011756f1272568d5a4(tree71bf58df).scripts/proof.pypassed all 7 gates in 501 s.99d8216b…, archived on the maintainer machine.tests/doctor_migrations.rsruns the real binary for bothdoctorandserveon each case. Every case failed against the pre-change code.success = 0;ok;tests/doctor_read_only.rs: with a changed checksum in a live writer's WAL, the database and WAL stay byte-identical. That test caught a deliberately injected doctor write in review. A separate test covers diagnosis in a read-only directory.Review And Merge Notes
249b2a3): 0 blocking.fail. The integrator decided on parity in both directions, implemented incab75e7with parity tests, along with the nits: message wording, a test's stated claim, an ordering comment, a zombie process, and a README wrap.249b2a3..cab75e7: self-reviewed by the integrator.doctornow catches a databaseservewould refuse.🤖 Generated with Claude Code