feat(accounts-controller): add support for Snap keyring v2#8513
feat(accounts-controller): add support for Snap keyring v2#8513
Conversation
ccharly
force-pushed
the
cc/feat/accounts-controller-snap-keyring-v2
branch
from
2851f32 to
235c68e
Compare
| const generatePatch = (): StatePatch => { | ||
| return { | ||
| previous: {}, | ||
| added: [], | ||
| updated: [], | ||
| removed: [], | ||
| }; | ||
| }; | ||
| const patches = { | ||
| snap: generatePatch(), | ||
| normal: generatePatch(), | ||
| }; | ||
|
|
||
| // Gets the patch object based on the keyring type (since Snap accounts and other accounts | ||
| // are handled differently). | ||
| const patchOf = (type: string): StatePatch => { | ||
| if (isSnapKeyringType(type)) { | ||
| return patches.snap; | ||
| } | ||
| return patches.normal; |
There was a problem hiding this comment.
Just removed all this since we don't need that separation at all!
| metadata: { | ||
| name: '', | ||
| importTime: Date.now(), | ||
| lastSelected: 0, | ||
| keyring: { | ||
| type: KeyringType.Snap, | ||
| }, | ||
| snap: { | ||
| name: keyring.snapId, | ||
| enabled: true, | ||
| id: keyring.snapId, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
The new Snap keyring v2 only use KeyringAccount, thus we don't have any metadata for those!
| snap: { | ||
| name: keyring.snapId, | ||
| enabled: true, | ||
| id: keyring.snapId, | ||
| }, |
There was a problem hiding this comment.
We could query this from the SnapController, but that requires a new allowed action, thus a breaking change (but at least that would mimic what the current big SnapKeyring is doing)
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c9d2191. Configure here.
| ...account, | ||
| // We still have to use internal account for now, so we inject some metadata. | ||
| metadata: { | ||
| name: '', |
There was a problem hiding this comment.
Snap v2 accounts permanently stuck with empty name
Medium Severity
#getAccountFromSnapKeyringV2 hardcodes metadata.name to ''. When the stateChange handler creates a v2 account, this empty name gets persisted. Later, updateAccounts attempts to assign a default name using existingAccount?.metadata.name ?? 'Snap Account X', but the nullish coalescing operator (??) does not treat empty strings as nullish, so '' ?? 'Snap Account 1' evaluates to ''. The account name can never be corrected to a proper default.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit c9d2191. Configure here.
1 participant
Explanation
Adding support for Snap keyring v2 for this controller. For now, those keyrings are not in use, but we will need this to be able to the accounts associated with those new keyrings.
References
N/A
Checklist
Note
Medium Risk
Adds a new Snap keyring v2 account ingestion path and alters keyring state synchronization logic, which could impact account discovery/selection if v2 keyrings are misidentified or return unexpected data.
Overview
Adds Snap Keyring v2 support in
AccountsControllerby recognizingKeyringType.Snapkeyrings and resolving accounts viaSnapKeyringV2.lookupByAddress, injecting minimal internal-account metadata (keyring + snap id) for backward compatibility.Refactors
KeyringController:stateChangesynchronization to use a single add/update/remove patch flow across keyring types, and updates helpers (keyringTypeToName,isNormalKeyringType, newisSnapKeyringV2Type) plus tests to cover v2 accounts and edge cases (missing keyring instance, account deleted before lookup). Changelog notes the addition and package scripts update messenger CLI formatting options.Reviewed by Cursor Bugbot for commit c9d2191. Bugbot is set up for automated code reviews on this repo. Configure here.