fix(vault): prove the rebuild really deployed, and report what it moved - #18
Merged
Conversation
A rebuild that silently deployed nothing would look identical to a working one, so assert the fresh schema carries every table before copying, and return per-table row counts for the Settings toast.
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
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
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
"Rebuild database" gave no evidence it did anything, so a skipped deploy would have been indistinguishable from a working one. Two changes, both about making the operation verifiable.
It cannot silently deploy nothing.
deployFreshnow checks the schema it just deployed before anything is copied into it:For the record on the original worry — pgpm skipping because of its ledger — that can't happen here:
registerPglite()hands back a brand-new in-memory PGlite with nopgpm_migrateschema at all (fast: truekeeps no ledger), so every rebuild is a first deploy. Verified directly: the log lines a rebuild emits are identical to first-run creation (Deploying local module: pgpm-verify / pgpm-base32 / pgpm-totp / dcrypt-vault), the rebuilt database has 9dcrypt_vaulttables and nopgpm*schema, and the copied ciphertext still decrypts under the same passphrase. The assert is there so a future pgpm that does decide to skip fails loudly instead of leaving an empty database.It says what it moved.
rebuild()returns the counts instead ofvoid:so Settings reports
Database rebuilt: 9 tables deployed, 34 rows carried over (12 items).rather than a flat "Every item was carried over."copyTablereturns its row count to feed that; no change to what it copies or to the on-disk format.Testing
packages/vault: 8 tests pass, including the rebuild test (which now also exercisesassertDeployed, since a rebuild that deployed nothing would throw before copying). Desktop lint, 27 tests and build pass.Link to Devin session: https://app.devin.ai/sessions/04636534e07048089ffb6b78142e12cd
Requested by: @pyramation