[pull] main from MetaMask:main#570
Merged
pull[bot] merged 7 commits intoReality2byte:mainfrom May 7, 2026
Merged
Conversation
## Explanation This PR implements quote polling for batched swap requests #### Changes - `updateBridgeQuoteRequest` now takes 2 extra params: the quote request’s index and the total quoteRequestCount within the batch. no changes in how we are using this handler for regular swaps - the new `selectBatchSellQuotes` selector returns the recommended quote for each quoteRequest, and aggregated amounts for display purposes - `isValidBatchSellQuoteRequest` #### Usage - the clients will need to maintain a list of requests, each one identified by an index. the index identifies the quoteRequest and its related side effects (quotes, metrics, submission etc) once it’s passed to updateBridgeQuoteRequest - to access quotes for a single quoteRequest, use the same index used during quoteRequest update #### Minimal client examples - extension: MetaMask/metamask-extension#42434. Checkout this branch and resolve the package locally to test - mobile: MetaMask/metamask-mobile#29831 <!-- 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 --> Fixes https://consensyssoftware.atlassian.net/browse/SWAPS-4443 ## 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** > This is a breaking API/state-shape change (`quoteRequest` becomes an array) that touches quote polling/streaming, analytics properties, and exchange-rate lookup logic; regressions could affect quote fetching and refresh behavior across swaps/bridges. > > **Overview** > **Adds BatchSell (batched swap) quote support** by changing `quoteRequest` state and polling inputs from a single request to an array, allowing callers to update a specific request via new `updateBridgeQuoteRequestParams(…, quoteRequestIndex, quoteRequestCount)` parameters. > > Quote fetching/streaming is updated to accept multiple requests: SSE uses a new `POST /getBatchQuoteStream` path when batching, tags incoming quotes with `quoteRequestIndex`, traces via new Sentry trace name `Batch Sell Quotes Fetched`, and adjusts polling stop/refresh logic to continue as long as *any* request is sufficiently funded. > > Selectors and rate lookup are extended for batching: adds `selectBatchSellQuotes` (per-request recommended quotes plus aggregated received/fee totals), switches exchange-rate selection to `selectExchangeRateByAssetId`, and exports `isValidBatchSellQuoteRequest`; tests/snapshots are updated and a new SSE batch test is added. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 9e2a7fa. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation Recently we added `createOriginMiddleware` to `v2` for usage in the clients. Though using it via `asLegacyMiddleware` introduces some complications, so for the time being we introduce the same middleware using the legacy API. ## 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 - [x] 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 - [x] 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 additive change: introduces a new legacy middleware and export without altering existing middleware behavior, with a small chance of conflicts for consumers that already attach an `origin` field to requests. > > **Overview** > Adds a legacy `createOriginMiddleware` for `@metamask/json-rpc-engine` that mutates the JSON-RPC request object to include an `origin` string (marked *deprecated* in favor of the v2 API). > > Exports the new utility from the package entrypoint, updates export snapshot tests, adds a unit test verifying `origin` is set, and records the addition in the package changelog. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 710f931. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…tSnaps` (#8725) ## Explanation Tracking account management Snaps so we can "restrict" the use of this service only for those Snaps. This will also be used later on to initialize their associated `SnapKeyring` v2. ## 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** > Changes `SnapAccountService.ensureReady` semantics to reject unknown/uninitialized Snap IDs and adds new messenger dependencies on `SnapController` lifecycle events, which could break existing consumers or event wiring if not updated. > > **Overview** > Adds `SnapTracker`, which seeds and maintains an in-memory set of *account-management Snaps* (installed/enabled, not blocked, and declaring `endowment:keyring`) based on `SnapController:getRunnableSnaps` plus `SnapController` lifecycle events. > > `SnapAccountService` now initializes this tracker in `init()`, exposes a new `getSnaps()` messenger method, and updates `ensureReady(snapId)` to **throw `Unknown snap: "<id>"`** unless the snap is currently tracked (effectively requiring callers to run `init()` and only use eligible Snaps). Tests and exports/changelog are updated accordingly, and the service messenger contract expands to include the new `SnapController` actions/events. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 48b03c9. 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? --> Releasing the bridge-controller package ## 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 - [x] 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 - [x] 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) - [x] 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** > Low code risk (mostly version/changelog updates), but **medium integration risk** because consumers of `@metamask/bridge-controller` are bumped to a new major version with breaking API changes (BatchSell quote batching). > > **Overview** > Bumps the monorepo release version to `967.0.0` and cuts `@metamask/bridge-controller` `72.0.0`, updating its changelog to document the **breaking** BatchSell quote batching changes. > > Updates `@metamask/bridge-status-controller` to `71.1.1` and `@metamask/transaction-pay-controller` to `22.0.1`, both primarily to depend on `@metamask/bridge-controller@^72.0.0`, with corresponding changelog and `yarn.lock` updates. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c5e2f5d. 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] > **Medium Risk** > Medium risk due to switching the RPC detector’s token-list API endpoint/caching behavior and adding new required NetworkController events, which can affect asset detection/refresh across networks for consumers. > > **Overview** > RPC token detection is reworked to use the same `token.api.cx.metamask.io/tokens/{chainId}` endpoint and filtering rules as `TokenListController`, including chain-specific `occurrenceFloor` handling, Linea aggregator filtering, and forwarding `iconUrl`/`aggregators` into detection results. A shared optional TanStack Query `queryClient` is introduced to cache/dedupe per-chain token-list fetches, and `AssetsController` now passes its existing API query client to `RpcDataSource` by default. > > `AssetsController` now listens for `NetworkController:networkAdded` and **new** `NetworkController:networkRemoved` events (breaking for restricted messengers) to force-refresh assets after network config changes, and refactors RPC custom-asset supplemental subscription selection into a pure helper. Fixes include making custom-asset spam-filter bypass case-insensitive in `TokenDataSource`, preventing `RpcDataSource` from clobbering enriched native metadata with stubs on refresh/error paths, and only graduating custom assets when upstream sources report a strictly positive balance. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4249719. 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] > **Medium Risk** > Mostly version/changelog updates, but it pulls in `@metamask/assets-controller@7.0.0` (breaking) and propagates that bump through bridge and transaction-pay packages, which can break downstream builds if messenger permissions aren’t updated. > > **Overview** > Bumps the monorepo release version to `968.0.0` and publishes `@metamask/assets-controller` as `7.0.0` (documenting the breaking change and new RPC token detection behavior). > > Propagates dependency/version bumps to align consumers: `@metamask/bridge-controller` `72.0.1` now depends on `@metamask/assets-controller@^7.0.0`, `bridge-status-controller` updates to `@metamask/bridge-controller@^72.0.1`, and `transaction-pay-controller` `22.0.2` bumps both dependencies; `yarn.lock` is updated accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 9032692. 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? --> This reverts commit 0caca27. This PR is faulty, because although it does restore retries for failed requests, it also causes `onDegraded` and `onBreak` to be fired for `RpcServiceChain`, and hence causes `NetworkController:rpcEndpointChainDegraded` and `NetworkController:rpcEndpointChainUnavailable` to be fired as well. ## 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] > **Medium Risk** > Changes `RpcService` retry/circuit-breaker behavior based on offline status, which can affect request reliability and when network degraded/unavailable events fire. Risk is mitigated by expanded unit/integration tests for offline scenarios. > > **Overview** > Reverts the previous behavior that continued retrying RPC requests while the user is offline by making `RpcService`'s retry filter short-circuit when `isOffline()` is true. > > This prevents offline connection failures from triggering retries, circuit breaks, and downstream NetworkController retry/degraded/unavailable event emissions, with updated/added tests covering offline unavailable and degraded scenarios and updated ESLint suppression metadata. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 263e1ca. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
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.
5 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 : )