[pull] main from MetaMask:main#534
Merged
pull[bot] merged 5 commits intoReality2byte:mainfrom Apr 23, 2026
Merged
Conversation
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> There is no written standard for defining the name of a controller, and some contributors do not have a common understanding of the do's and dont's for the name. This commit adds such a guideline, highlighting the following points: - The name of a controller should be defined in a variable called `CONTROLLER_NAME` (formerly `controllerName`) - The name should be used to define custom actions and events and should be passed to `BaseController` - The name should not be exported from the package Besides updating the guidelines, this commit also updates the `sample-controllers` package to follow them, most notably changing `controllerName` to `CONTROLLER_NAME` and removing the `export` from this constant. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [x] 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** > Removes an exported constant and renames `controllerName` to `CONTROLLER_NAME` in sample controllers, which could break any consumers importing that symbol even though runtime behavior is unchanged. > > **Overview** > Adds a new controller guideline requiring a single internal `CONTROLLER_NAME` constant to namespace messenger actions/events and `BaseController` state, and explicitly discouraging exporting that constant from the package. > > Updates the `sample-controllers` examples (`sample-gas-prices-controller` and `sample-petnames-controller`) to follow the guideline by replacing exported `controllerName` with an internal `CONTROLLER_NAME` and wiring all messenger/type and `BaseController` references to it. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4757fdb. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
Reverts #8569 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk because this PR only reverts package versioning/changelog metadata and downgrades internal dependency ranges; no runtime code changes are included. > > **Overview** > Reverts the `934.0.0` release metadata by rolling back the monorepo and several package versions (`bridge-controller`, `bridge-status-controller`, `perps-controller`, `transaction-pay-controller`). > > Updates changelog compare links/headers accordingly and downgrades `@metamask/bridge-controller` / `@metamask/bridge-status-controller` dependency ranges in downstream packages, with corresponding `yarn.lock` adjustments. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 826c037. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…over multiple keyrings (#8416) ## Explanation Today there's no way to make multiple operations in an "atomic" (read transactional) way. A good example of this is if you want to use a keyring using `withKeyring` that's not existing yet (I'm omitting the `createIfMissing` variants, as we wanted to move away from this pattern). To do this in a safe way, you usually have to use your own lock to make sure you can get-or-create the keyring and prevent concurrent keyring creations. This new `withController` is based on the `withKeyring` but with an access to a "restricted" state and methods of the controller. This way, you can interact with multiple keyring at once while being guarded (to prevent race-conditions) by the controller's global lock. The former problem can then be written that way now: ```ts const account = await keyringController.withController(async (controller) => { // Here, `controller.keyrings` is a "view" on the existing keyrings (instances), only valid // for this block. let keyring: MyKeyring | undefined = controller.keyrings.find(isMyKeyring); if (!keyring) { const { keyring: myKeyring } = await controller.addNewKeyring({ type: 'My Keyring', data: { ... }}); keyring = myKeyring; } const [account] = await keyring.createAccounts(...); return account; }); ``` This will also be used to write the migration from the existing `SnapKeyring` (1 for ALL Snaps) to multiple `SnapKeyring` (1 PER Snap) in a safe way like: ```ts await keyringController.withController(async (controller) => { const accounts: Map<SnapId, KeyringAccount[]> = new Map(); // Get existing Snap accounts from the single Snap keyring instance we have today. const keyring: SnapKeyring | undefined = controller.keyrings.find(isSnapKeyring); if (keyring) { for (const account of keyring.listAccounts()) { accounts[account.metadata.snap.id] ??= []; accounts[account.metadata.snap.id].push(account); } } // Re-create all new Snap keyrings, 1 per Snap. for (const [snapId, snapAccounts] of accounts.entries()) { await controller.addNewKeyring({ type: 'Snap keyring', data: snapAccounts }); } // We can safely remove the existing Snap keyring now. await controller.removeKeyring(...); }); ``` ## References N/A ## 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** > Adds a new transactional API that can create/remove keyrings and then persist/rollback state, which touches keyring lifecycle and vault persistence paths. Risk is moderate due to potential edge cases around staged mutations, keyring destruction, and primary keyring protection. > > **Overview** > Adds `KeyringController.withController` (and messenger action `KeyringController:withController`) to run **single-lock, atomic operations across multiple keyrings** via a `RestrictedController` that exposes a live read-only view plus staged `addNewKeyring`/`removeKeyring` mutations. > > On success it commits staged keyring list changes, persists via existing persist/rollback flow, and destroys removed keyrings; on error it rolls back and destroys any newly created keyrings. The PR also blocks removal of the primary HD keyring (`CannotRemovePrimaryKeyring`), extends `KeyringEntry`/callback typings, updates mocks to include `destroy`, and adds comprehensive unit + messenger tests for the new behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 0ae24f6. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
… messenger (#8561) ## Explanation This updates the `CurrencyRateController` to expose all methods through the messenger in a standardized way. ## 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** > Medium risk because it introduces a **breaking** rename of the `CurrencyRateController` get-state action type and changes the controller’s messenger surface area, requiring downstream type/import updates. > > **Overview** > `CurrencyRateController` now exposes `setCurrentCurrency` and `updateExchangeRate` via the messenger by registering method action handlers, and adds generated method action type definitions for these calls. > > This standardizes/renames the get-state messenger action type from `GetCurrencyRateState` to `CurrencyRateControllerGetStateAction` (type-only breaking change) and updates internal consumers (`MultichainAssetsRatesController`, `TokenSearchDiscoveryDataController`, and `bridge-controller`) plus exports the new action types from `assets-controllers`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ee67d75. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## 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] > **Low Risk** > Low risk because this PR only updates package versions, changelogs, and dependency ranges/lockfile entries without any source code logic changes. > > **Overview** > Bumps the monorepo release to `934.0.0` and publishes new versions of `@metamask/bridge-controller` (`70.2.0`), `@metamask/bridge-status-controller` (`71.0.0`), `@metamask/perps-controller` (`4.0.0`), and `@metamask/transaction-pay-controller` (`19.3.0`). > > Updates corresponding changelog sections and compare links, and aligns downstream dependency ranges (notably `transaction-pay-controller` and `bridge-status-controller`) plus `yarn.lock` to reference the new bridge package versions. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3aa4d08. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Maarten Zuidhoorn <maarten@zuidhoorn.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )