feat(account-tree-controller)!: add {import,export}State actions - #9663
Draft
ccharly wants to merge 62 commits into
Draft
feat(account-tree-controller)!: add {import,export}State actions#9663ccharly wants to merge 62 commits into
{import,export}State actions#9663ccharly wants to merge 62 commits into
Conversation
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Contributor
Author
|
@metamaskbot publish-preview |
ccharly
changed the title
{import,export}State actions{import,export}State actions
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
4 tasks
pull Bot
pushed a commit
to dmrazzy/core
that referenced
this pull request
Aug 10, 2026
… `ensureReady` (MetaMask#9812) ## Explanation If we try to create a multichain account wallet during onboarding, the post-alignment part (e.g. non-EVM account creations) is locking this wallet's lock until onboarding is completed. This prevents any other kind of operations on that wallet that requires the wallet's mutex to be locked again. This is what we do now for the QR sync wallet during onboarding, like: - 1 - QR sync payload is received - 2 - The primary SRP gets created (onboarding still pending) - Post-alignment is scheduled and **LOCKS the wallet's mutex** (non-EVM creation part, since `waitForAllProvidersToFinishCreatingAccounts=false`) - 3 - Password is set (onboarding still pending) - Vault got created now, we proceed with the rest of QR sync flow (remaining wallets + importing metadata) - 4 - We try to import wallet's metadata for the primary wallet - 💥 **Wallet's mutex is already LOCKED (during step 2)**, the onboarding cannot proceed -> deadlock 💥 To prevent this from happening, we now guard every post-alignment with a call to `ensureReady` on each providers before proceeding. This makes sure we only schedule wallet's operation once the providers are ready to proceed anything. In the case of the `SnapAccountProvider`, this means they will wait for the Snap platform to boot up before starting to lock the wallet's mutex, solving the initial issue "naturally". ## References - MetaMask#9663 ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes wallet locking order during group creation—a sensitive concurrency path—but scope is limited to deferred post-alignment and includes tests for lock timing and partial provider failure. > > **Overview** > Fixes a **deadlock during onboarding** when non-EVM post-alignment ran under the wallet mutex while Snap providers were still waiting for the platform—blocking later steps such as QR sync metadata import. > > **Fire-and-forget post-alignment** (when `waitForAllProvidersToFinishCreatingAccounts` is false) now calls **`ensureReady` on all non-EVM providers before** acquiring the alignment lock. Only providers that become ready are aligned; failures are logged and skipped so a later explicit alignment can recover them. > > The **`ensureReady`** hook is added to the BIP-44 provider contract (no-op on base/EVM, delegated through **`AccountProviderWrapper`**, Snap waits via **`SnapAccountService:ensureReady`**). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 954eab5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Contributor
Author
|
@metamaskbot publish-preview |
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
New
{export,import}Stateactions.This is the implementation for this ADR:
References
Checklist