fix(cli): refuse a newer database schema with an actionable error - #134
Merged
Conversation
…t a bare version number Store::open keeps strict migration validation — an older binary must never run against a schema written by a newer one (undefined behavior on the billing-critical event log beats no startup exactly never). But the refusal now says what happened and how to recover: Error::SchemaNewer names the db path, the unknown migration, and both fixes (dira update, or pinning back to the version that wrote it), instead of sqlx VersionMissing respawn-looping under launchd with a cryptic number. Records DIRASH-0035 (ignore_missing rejected; strict is the correct half, the message was the broken half). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Asen Lekov <asenlekoff@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
An older
diradmeeting adira.dbwritten by a newer version failssqlx's strict migration validation with a bareVersionMissing(<number>)and respawn-loops under launchd — the only diagnosis is a cryptic number in the log. This matters becausedira update --version <older>is a documented recovery flow, and it affects every migration, not just new ones.The policy decision (DIRASH-0035)
Strict validation stays. The evaluated alternative —
Migrator::set_ignore_missing(true)— would let the older binary run against a schema written by a future version: newer migrations may add required columns or change semantics, so a clean startup refusal would be traded for undefined runtime behavior on the event log that feeds billing and identity. That contradicts the codebase's standing doctrine (doctor reports and never repairs, DIRASH-0022; a replacement daemon is never started on optimism, D-0019). The respawn loop is supervision working as configured; the bug was the message.What changed
Store::opencatchesMigrateError::VersionMissingand returns a newError::SchemaNewernaming the db path, the unknown migration, the cause, and both recovery paths (dira update, ordira update --version <the writer's version>)._sqlx_migrations, asserts reopen refuses with the actionable message..zavet/decisions/DIRASH-0035documents why strict is correct and whyignore_missingwas rejected.Testing
cargo test -p dira-core: 308 passed, 0 failed. Clippy-D warningsclean, fmt clean. Based ondevelop; merges cleanly with #133 (itsStore::openhunks don't overlap).🤖 Generated with Claude Code