Fix: saving serialized keyring for which corresponding keyring class is not present #169
Conversation
…ype is not present
test/index.js
Outdated
| @@ -94,6 +94,28 @@ describe('KeyringController', function () { | |||
| }); | |||
| }); | |||
|
|
|||
| describe('persistAllKeyrings', function () { | |||
| it('should persist keyrings in unsupported_keyrings array', async function () { | |||
There was a problem hiding this comment.
Why are we putting all of the keyrings in unsupported_keyrings when persistAllKeyrings is called? It makes sense that unsupported_keyrings would hold all keyrings that we can't find a Keyring class for, but that doesn't seem to be what this is doing. So I'm a bit confused as to how unsupported_keyrings would end up getting used.
There was a problem hiding this comment.
persistAllKeyrings is reading from unsupported_keyrings, not writing to it. We're persisting the unsupported keyrings so that they remain in the users vault, in case they need to manually extract them, or in case we add back support for that keyring.
I can see how this description could be read either way. It doesn't mean the keyrings are being persisted to that array, just that that array is included in the set of data being persisted.
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
There was a problem hiding this comment.
LGTM!
I agree with @mcmire that we should have a test for restoreKeyring, and I've left a few more suggestions on improving the tests. But I didn't want to block on those; the tests here already aren't in great shape. The basic functionality is at least covered.
test/index.js
Outdated
| describe('persistAllKeyrings', function () { | ||
| it('should persist keyrings in unsupportedKeyrings array', async function () { | ||
| const unsupportedKeyring = 'DUMMY_KEYRING'; | ||
| keyringController.unsupportedKeyrings = [unsupportedKeyring]; |
There was a problem hiding this comment.
Nit: It would be better for this test to set the keyrings in the same way the extension would. We wouldn't ever use the keyring controller this way, setting the unsupportedKeyrings property directly.
Unfortunately the way these tests are setup makes that difficult. The extension passes in existing vaults via the constructor, but these tests all construct the controller the same way in beforeEach. This is why we've been recommending that people avoid using beforeEach, and use setup functions instead. Then we can create new setup functions tailored for specific tests. Improving this test in the way I'm suggesting here might require a similar refactor of the other tests first.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
| */ | ||
| async _restoreKeyring(serialized) { | ||
| const { type, data } = serialized; | ||
|
|
||
| const Keyring = this.getKeyringClassForType(type); | ||
| if (!Keyring) { | ||
| this._unsupportedKeyrings.push(serialized); | ||
| return undefined; |
There was a problem hiding this comment.
hi @jpuri, late question: when we support hard wallets for MV3, will this logic added in this PR still be needed?
Fixes: MetaMask/metamask-extension#16674
For MV3 currently we are not supporting hardware wallets, this can result in error being thrown if Keyring classes of hardware wallets is not passed to Keyring Controller.
PR fixes the error by adding
nullcheck. Keyring for which corresponding keyring class is not present is saved in state and then re-serialized.