feat(keyring-controller): persist vault when keyring state changes during unlock#8415
Open
feat(keyring-controller): persist vault when keyring state changes during unlock#8415
Conversation
…ring unlock Introduces `hasStateChanged` helper and uses it to detect when a keyring's serialized state differs from what was stored in the vault. If any keyring changed during deserialization (e.g. ran a migration, or was missing metadata), the vault is re-persisted via the existing upgrade path in `submitPassword`/`submitEncryptionKey`. Also removes the now-redundant `isEqual` import from lodash.
…low serialize() Eagerly stringify session state before the operation so that subsequent mutations to keyring-internal arrays (e.g. MockShallowKeyring) cannot retroactively change the snapshot used for comparison. Also removes the now-unnecessary `hasStateChanged` helper.
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.
Explanation
Currently, if a keyring runs a migration inside
deserialize()during unlock, the updated in-memory state is never written back to the vault. On the next unlock the migration silently re-runs against the same stale data.This PR fixes that by comparing each keyring's re-serialized state against the original data after
#restoreKeyring. If any keyring's state differs — whether due to a migration or missing metadata —hasChangedis propagated up through#restoreSerializedKeyringsand#unlockKeyrings, and the existing vault upgrade path insubmitPassword/submitEncryptionKeyre-persists the vault.As part of this change, a
hasStateChangedhelper function is introduced and reused in#persistOrRollback, removing the dependency on lodashisEqualfor that comparison.References
Checklist
Note
Medium Risk
Touches the unlock flow and vault persistence logic; an incorrect change-detection signal could trigger unnecessary vault rewrites or miss persisting a migrated keyring state.
Overview
Ensures the vault is re-persisted after unlock when deserializing keyrings results in a different serialized state (e.g. keyring migrations running during
deserialize()or missing keyring metadata being regenerated), preventing repeated migrations on subsequent unlocks.This propagates a
hasChangedflag through#restoreKeyring→#restoreSerializedKeyrings→#unlockKeyringsand uses it insubmitPassword/submitEncryptionKeyto conditionally call#updateVault. It also simplifies session-state change detection in#persistOrRollbackby switching from lodashisEqualto direct JSON string comparison and drops theisEqualimport.Reviewed by Cursor Bugbot for commit 0fd1697. Bugbot is set up for automated code reviews on this repo. Configure here.