[pull] main from MetaMask:main#782
Merged
Merged
Conversation
This reverts commit 639fc11. ## 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: this PR mainly reverts package version numbers and dependency bumps, with no functional code changes; risk is limited to release/versioning consistency across packages. > > **Overview** > Reverts the prior `976.0.0` release version bumps across the monorepo, rolling back workspace/package versions for `@metamask/assets-controller`, `@metamask/assets-controllers`, `@metamask/bridge-controller`, `@metamask/bridge-status-controller`, and `@metamask/transaction-pay-controller`, along with their internal dependency ranges. > > Updates associated `CHANGELOG.md` files by removing the newly introduced release sections and adjusting the *Unreleased* compare links to point back to the previous released versions, and updates `yarn.lock` to match the reverted dependency versions. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit aefd5b1. 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** > Primarily a version/changelog release bump, but it updates to `@metamask/assets-controllers@107.0.0` which includes a **breaking** API change (`getTrendingTokens` parameter rename) that can affect downstream consumers. > > **Overview** > Updates the repo for the `976.0.0` release by bumping package versions and refreshing changelogs. > > This release rolls forward dependency ranges across controllers (notably `@metamask/assets-controller@7.1.0`, `@metamask/assets-controllers@107.0.0`, `@metamask/bridge-controller@72.0.3`, and `@metamask/bridge-status-controller@71.1.3`) and updates `yarn.lock` accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit d4802b8. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation Release new versions of the chomp-api-service and money-account-upgrade-controller <!-- 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: this PR only updates package versions, changelogs, and dependency pins/lockfile entries with no code changes. > > **Overview** > Bumps the monorepo version to `977.0.0` and releases `@metamask/chomp-api-service@3.1.0` (documenting the updated retry policy that avoids retrying most 4xx responses). > > Releases `@metamask/money-account-upgrade-controller@2.0.0` and updates it to depend on `@metamask/chomp-api-service@^3.1.0`, with corresponding `CHANGELOG.md` and `yarn.lock` updates. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit aa8e6c4. 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 new `network-controller` major version and `controller-utils` minor version, along with all their peers ## 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 and dependency bumps across the monorepo, but it pulls in `@metamask/network-controller@32.0.0` (breaking default-network set changes) which can affect consumers’ network availability and initialization assumptions. > > **Overview** > Updates the monorepo release to `978.0.0` and publishes new package versions across many workspaces. > > Propagates dependency bumps for the `@metamask/network-controller@32.0.0` major and `@metamask/controller-utils@12.1.0` minor (plus related peer bumps like `@metamask/accounts-controller@38.1.1`, `@metamask/assets-controllers@108.0.0`, and `@metamask/signature-controller@39.2.2`), with corresponding `package.json` and `CHANGELOG.md` updates throughout. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 7ef6440. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…t fiat order metadata (#8694) ## Explanation ### 1. Derive fiat order `sourceAmount` from on-chain tx data Currently, the fiat submit flow derives `sourceAmountRaw` from `order.cryptoAmount` - a human-readable value reported by the on-ramp provider. This value may not precisely reflect what was actually received on-chain. This PR reads the actual transferred amount from the completed on-chain transaction (`order.txHash`) instead. For native tokens, the amount is taken from `tx.value`. For ERC-20 tokens, the amount is decoded from the `transfer(address,uint256)` call data. If the on-chain read fails or the transaction hash is missing, the existing `order.cryptoAmount` derivation is used as a fallback. The implementation introduces: - **`getTransferredAmountFromTxHash`** - a generic utility in `utils/transaction-receipt.ts` that reads transferred amounts from any on-chain transaction (native or ERC-20). Takes explicit `chainId` and `tokenAddress` params for reusability. - **`resolveSourceAmountRaw`** - a fiat-strategy-specific function in `strategy/fiat/utils.ts` that orchestrates the on-chain read with `order.cryptoAmount` fallback. - **`getRawSourceAmountFromOrderCryptoAmount`** - the existing decimal-shift conversion, moved from `fiat-submit.ts` to `strategy/fiat/utils.ts` and renamed for clarity. ### 2. Persist fiat order metadata on `metamaskPay` The `TransactionPayController` state is cleaned up when a transaction is finalized (confirmed/failed/dropped). This means `fiatPayment.orderId` and the provider info are gone by the time the user opens the activity/transaction-details view. To enable the mobile activity view to show a fiat order status row (and query `RampsController:getOrder` for live status), this PR persists the fiat order ID and provider code on `transaction.metamaskPay` **before** polling begins in `submitFiatQuotes`. Changes: - **`MetamaskPayMetadata`** (`transaction-controller/types.ts`) — Added `fiatOrderId?: string` and `fiatProvider?: string` fields. - **`submitFiatQuotes`** (`fiat-submit.ts`) — Calls `updateTransaction` to persist `fiatOrderId` and `fiatProvider` on `tx.metamaskPay` before `waitForOrderCompletion` starts polling. This ensures data is available even while the order is still in-flight. - **Tests** — Two new tests verify metadata persistence and that existing `metamaskPay` fields are preserved. ## References - Related to the fiat strategy submit flow introduced in #8347 ## 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] > **Medium Risk** > Updates fiat on-ramp submission to depend on on-chain receipt/trace parsing and persists new metadata onto `TransactionMeta`, which could affect payment execution and activity display if RPC methods/log parsing behave unexpectedly across networks. > > **Overview** > Fiat on-ramp submit flow now **persists order identifiers** onto `transaction.metamaskPay.fiat` (order ID + provider code) before polling, so downstream activity views can query order status even after controller state cleanup. > > The relay leg’s `sourceAmountRaw` is now **derived from the actual on-chain transfer** referenced by `order.txHash` via new utilities that parse ERC-20 `Transfer` logs or native transfers (using `debug_traceTransaction` with a `tx.value` fallback), falling back to `order.cryptoAmount` conversion when on-chain reads are unavailable. > > Adds `MetamaskPayMetadata.fiat` to the transaction-controller types and updates/extends unit tests around fiat submission, amount resolution, and receipt/trace parsing. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 46177a2. 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.
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 : )