feat: erase all local data, and rebuild the vault database in place - #17
Merged
Conversation
🤖 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
Two Settings actions, both about the local database.
Erase all data (destructive, type
ERASEto confirm) deletes everything dcrypt keeps on the machine — the whole appstash root, so the vault snapshot, keychain and identity file go with it — and drops the renderer back to the create-vault screen. The next "Create vault" re-runs the pgpm deploy exactly like a first run, so redeploying after a wipe needs nothing separate.The subtlety is that erasing must not persist on the way out.
lock()saves first, which would rewrite the file we are about to delete (or recreate it after deletion), so the vault grew a sibling:VaultService.eraseAll()cancels the debounced save timer, awaits any in-flight lock,discard()s, thenfs.rm(appDataPath(), { recursive: true }). Backups the user saved elsewhere are untouched.Rebuild database re-runs the pgpm deploy into a fresh PGlite and moves every row across, for when a module version changes the schema under an existing vault. It copies at the row level rather than through the public API, so nothing is decrypted and nothing is re-keyed:
COPY_ORDERwalks meta → folders → items → fields → password_history → tags → item_tags → urls → audit_log so foreign keys are satisfied as it goes; folders are inserted withparent_idnull and re-attached in a second pass because of their self-reference. Item/field/folder ids are preserved, so a one-time code produces the same digits before and after. The old database is only closed once the copy succeeds — a failure closes the fresh one and leaves the live vault untouched.Tests:
rebuild()round-trips a nested folder, a favorite login with concealed and unconcealed fields, a URL, a tag and a TOTP seed (asserting the same code afterwards, and again after lock/reopen);discard()is asserted to leave post-save edits on the floor.Link to Devin session: https://app.devin.ai/sessions/04636534e07048089ffb6b78142e12cd
Requested by: @pyramation