[pull] main from MetaMask:main#642
Merged
pull[bot] merged 8 commits intoReality2byte:mainfrom Mar 31, 2026
Merged
Conversation
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** - Create a centralized workflow Runway OTA Build Core that decide either to run an OTA update or start a new build based on if there is an OTA version change - All 4 workflows use Runway OTA Build: runway-android-production-workflow.yml, runway-android-rc-workflow.yml, runway-ios-rc-workflow.yml and runway-ios-production-workflow.yml - Create a workflow to tag branch if it's an OTA update: runway-create-ota-production-tag.yml Note: all ios workflows (rc and production) will not skip version bump but Android will. That's because we only want to bump version once. runway-android-rc-workflow (build): https://github.com/MetaMask/metamask-mobile/actions/runs/23557585480 runway-ios-rc-workflow (build): https://github.com/MetaMask/metamask-mobile/actions/runs/23557559865 runway-android-rc-workflow (OTA): https://github.com/MetaMask/metamask-mobile/actions/runs/23561069878 runway-ios-rc-workflow (OTA): https://github.com/MetaMask/metamask-mobile/actions/runs/23561062779 ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Added runway production workflows ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes GitHub Actions release automation for OTA updates, builds, and tagging; mistakes could misroute production OTAs, skip version bumps, or create incorrect tags/artifacts. > > **Overview** > Adds dedicated Runway `workflow_dispatch` entrypoints for **iOS/Android RC and production** that call a reusable `runway-ota-build-core.yml`, wiring platform/channel/build-name differences and enabling TestFlight upload for iOS. > > Refactors `runway-ota-build-core.yml` to be `workflow_call`-driven with new inputs (e.g., `platform`, `ota_channel`, `build_name`, `skip_version_bump`, `upload_testflight`) and updates OTA dispatch to use `actions/github-script@v7` plus parameterized channel/platform and artifact naming. > > Introduces reusable `runway-create-ota-production-tag.yml` to create an annotated `v*` tag after a successful **production OTA** (idempotent, refuses to move existing tags), and removes the legacy `runway_android_rc_workflow.yml` in favor of the new structure. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit a54a664. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> The Ramps lane has been renamed to **Money Movement** on GitHub ([`@MetaMask/money-movement`](https://github.com/orgs/MetaMask/teams/money-movement)). This updates `.github/CODEOWNERS` so review requests and branch-protection ownership resolve to the current org team instead of `@MetaMask/ramp`. **What changed** - Section comment renamed to **Money Movement Team (formerly Ramps)**. - All `@MetaMask/ramp` entries replaced with `@MetaMask/money-movement` (Ramp UI, fiat orders, ramps controller/messengers, selectors, path globs, and Swaps co-owned `parseAmount` / `parseAmount.test.ts`). - Co-ownership comment updated to reference Money Movement alongside Swaps. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: CODEOWNERS ownership update Scenario: No in-app verification required Given this pull request only changes .github/CODEOWNERS When reviewers validate the team slug and paths Then no wallet UI or device manual test is applicable ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk because it only updates `.github/CODEOWNERS` mappings; the main impact is on review routing/branch protection if any paths or the new team slug are incorrect. > > **Overview** > Updates `.github/CODEOWNERS` to reflect the GitHub team rename from `@MetaMask/ramp` to `@MetaMask/money-movement` for Ramp-related paths (UI, fiat orders, ramps controllers/messengers, selectors, and related glob patterns). > > Adds an additional `**/money-movement/**` ownership rule and updates the Swaps co-owned `parseAmount` entries to use the new Money Movement team. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8efd4d2. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…#28057) <!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## **Description** Implements balance-aware Swap defaults **only for the sticky Swap button in Token Details**. When users tap the sticky Swap CTA from Token Details: - If the viewed token has a positive balance, Swap opens with: - `From = current token` - `To = swap default` - If the viewed token has zero balance, Swap opens with: - `From = best available token (same existing selection logic used by sticky Buy flow)` - `To = current token` Scope is intentionally narrow to avoid regressions in other swap entry points: - Added a dedicated `handleStickySwapPress` in `useTokenActions` - Wired `TokenDetailsStickyFooter` to call `onSwap` (sticky-only handler) - Kept existing non-sticky/legacy swap navigation behavior unchanged - Updated Security & Trust screen to continue using generic swap behavior ## **Changelog** CHANGELOG entry: Fixed Token Details sticky Swap button defaults to use a balance-aware source token selection. ## **Related issues** Fixes: N/A Refs: https://consensyssoftware.atlassian.net/browse/ASSETS-2972 #28050 ## **Manual testing steps** ```gherkin Feature: Token Details sticky swap defaults Scenario: Token has positive balance Given user has balance in token X And user opens Token Details for token X When user taps the sticky Swap button Then Swap opens with token X as the source token And destination token is not prefilled as token X Scenario: Token has zero balance but user has other eligible assets Given user has zero balance in token X And user has positive balance in another eligible token Y And user opens Token Details for token X When user taps the sticky Swap button Then Swap opens with token Y as the source token And token X is prefilled as the destination token Scenario: Legacy/non-sticky swap path remains unchanged Given user opens Token Details When user navigates via non-sticky swap entry path Then existing swap defaults behave as before ``` ## **Screenshots/Recordings** ### **Before** N/A ### **After** Tested in Offsite - Approval from @bergarces and @AmarildoGr ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-ed6f6ce0-7d90-490a-8fa8-8d10df762d55"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-ed6f6ce0-7d90-490a-8fa8-8d10df762d55"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Prithpal Sooriya <prithpal.sooriya@users.noreply.github.com>
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> This PR is the first part of Braze integration. It's currently only creating Braze users based on their profile id, and registering their FCM/APN tokens to start filling up Braze database with tokens. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Added Braze SDK to enhance push notifications capabilities ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/GE-107 ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Adds a new third-party push/engagement SDK and changes native push handling/initialization on both iOS and Android, which could affect notification delivery and app startup. Build tooling changes (Kotlin forcing + patched dependency) also increase risk of platform-specific build regressions. > > **Overview** > Introduces Braze as a new mobile dependency and wires it into both native platforms to start registering push tokens and supporting Braze-driven notifications. > > On **Android**, adds Braze API key/endpoint injection via Gradle resources, registers `BrazeFirebaseMessagingService` as the primary FCM handler with a fallback to the existing RN Firebase service, and initializes Braze lifecycle callbacks; it also pins Kotlin/serialization versions and patches `@braze/react-native-sdk` to keep builds compatible with Kotlin 1.9. > > On **iOS**, adds Braze keys to Info.plists and initializes a shared `Braze` instance in `AppDelegate` using build-injected credentials, enabling Braze push automation while preserving the existing permission flow. > > On the JS side, adds a small `app/core/Braze` layer plus `useBrazeIdentity` hooked into `useIdentityEffects` to call `Braze.changeUser(profileId)` on sign-in (skipped in E2E), along with Jest mocks/tests and new build/CI env vars for Braze secrets (examples, `build.sh`, workflow, and config verification). > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 29b58cd. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> This change separates swaps-trending token detail navigation from the generic explore trending flow so MetaMetrics can attribute those entry points correctly. It adds a dedicated `trending-swaps` token details source, passes that source from the Bridge/Swaps trending section into `TrendingTokenRowItem`, and keeps the default `trending` source for existing explore-tab behavior. The added test coverage verifies the swaps-trending navigation params include the new source. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: [SWAPS-4306](https://consensyssoftware.atlassian.net/browse/SWAPS-4306) ## **Manual testing steps** ```gherkin Feature: Swaps trending token source tracking Scenario: user opens token details from swaps trending Given the app is running and the Bridge/Swaps trending tokens section is visible When the user taps a token from the Bridge/Swaps trending tokens list Then the Asset route is opened for that token And the token details navigation params use the source "trending-swaps" Scenario: user opens token details from explore trending Given the app is running and the Explore trending tokens list is visible When the user taps a token from the Explore trending list Then the Asset route is opened for that token And the token details navigation params continue to use the source "trending" ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- Generated with the help of the pr-description AI skill --> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Small, scoped change to navigation params/analytics attribution with a default preserving existing behavior; minimal functional risk aside from potential analytics mislabeling if miswired. > > **Overview** > Routes opened from the Swaps/Bridge trending tokens section now pass a dedicated token-details `source` value (`TokenDetailsSource.TrendingSwaps`) instead of the generic trending source, allowing analytics to distinguish entry points. > > This introduces the new `trending-swaps` enum value, adds an optional `tokenDetailsSource` prop to `TrendingTokenRowItem` (defaulting to `Trending`), and updates tests to assert the Bridge section forwards the source and that navigation params include `source: 'trending-swaps'` when provided. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 6909921. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…mations (#28136) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Removes `selectMultichainAccountsState2Enabled` selector usage from the confirmations area now that the multichain accounts State 2 / BIP-44 feature is considered stable. The legacy code path (when the flag returned `false`) is no longer needed. Changes: - Simplified `useSendScope` hook to always return State 2 behavior (`isBIP44: true`, `isSolanaOnly: false`, `isEvmOnly: false`), removing the `selectMultichainAccountsState2Enabled` and `selectSelectedInternalAccount` selector dependencies. - Removed `isBIP44` branching in `RecipientList` -- accounts always render as BIP44-grouped list; contacts always render as flat list. - Removed `isBIP44` prop from `Recipient` component -- always displays `accountGroupName` (State 2 behavior) instead of conditionally choosing between `accountGroupName` and `accountName`. - Removed dead `isSolanaOnly` early-return in `useEVMNfts` hook (always `false` under State 2). - Cleaned up 7 test files: removed selector mocks, deleted legacy-path test suites, updated mock data. <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1088 ## **Manual testing steps** ```gherkin Feature: Confirmation screens after removing multichain State 2 feature flag Scenario: Send flow shows grouped recipient list Given the user has multiple wallets with accounts When the user navigates to the Send screen And selects a recipient from the account list Then the accounts are grouped by wallet name And each account displays its account group name Scenario: Send flow shows flat contact list Given the user has saved contacts When the user navigates to the Send screen And switches to the Contacts tab Then the contacts are displayed in a flat list under a "Contacts" header Scenario: Personal sign confirmation renders correctly Given the user has a pending personal_sign request When the user views the confirmation screen Then the request origin, message, and account info are displayed correctly Scenario: Typed sign confirmation renders correctly Given the user has a pending eth_signTypedData request When the user views the confirmation screen Then the typed data fields and network info are displayed correctly Scenario: Approve/send transaction confirmation renders correctly Given the user initiates a token send or approve transaction When the user views the confirmation screen Then the sender account info, network, and transaction details are displayed correctly ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Removes feature-flag/legacy branching in confirmation send UI and NFT hook behavior, which can change what names/lists render in edge cases. Mostly refactor/deletion, but touches user-facing recipient display and list grouping. > > **Overview** > **Confirmations no longer branch on the multichain State 2/BIP-44 feature flag.** Recipient UI is simplified to always display `accountGroupName` (falling back to `contactName`) and drops the `isBIP44` prop. > > Send recipient lists now always group accounts by `walletName` (BIP-44-style) while contact lists stay flat with a fixed "Contacts" header, and the `useSendScope` hook and its tests are removed. `useEVMNfts` also drops the Solana-only early-return, with tests updated/trimmed to reflect the new single-path behavior and removed selector mocks. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 7dceb22. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> `@metamask/tron-wallet-snap` has been updated to `^1.25.0` to include the following changes: ```markdown ## [1.25.0] ### Changed - Optimize account discovery by using a lightweight activity check (`limit=1`) instead of fetching full transaction history ([#252](MetaMask/snap-tron-wallet#252)) ### Fixed - Avoid `onAmountInput` fee estimation failures by skipping fee validation until a recipient address is available ([#259](MetaMask/snap-tron-wallet#259)) - Assert transaction structure at all entry points, rejecting malformed transactions ([#237](MetaMask/snap-tron-wallet#237)) - Disable scanning of unsupported contract types, preventing incorrect security alerts from blocking user flows ([#238](MetaMask/snap-tron-wallet#238)) - Supported transactions are those single-contract interaction transactions of the following types: `TransferContract`, `CreateSmartContract`, `TriggerSmartContract`. - Unsupported transactions will show empty estimated changes and allow the user to proceed without blocking the confirmation. - Correctly fetch and return staking rewards ([#242](MetaMask/snap-tron-wallet#242)) - Fix revert simulation error when sending TRC20 tokens ([#261](MetaMask/snap-tron-wallet#261)) - Fix infinite loading during fee estimation ([#258](MetaMask/snap-tron-wallet#258)) - The issue was caused by a deadlock during cache updates of chain parameters. ``` ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Fixed a bug that was causing issues with TRC20 token transfers ## **Related issues** Fixes: ## **Manual testing steps** 1. Initiate a TRC20 token transfer (e.g., USDT) 2. Type in a valid recipient address and amount 3. Observe that the button does not show an error 4. Click the button to proceed with the transfer 5. Observe that the confirmation screen is shown with no simulation error ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> https://github.com/user-attachments/assets/e7b55fc3-9e80-4b44-8558-4cbbd9d38f62 ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Dependency-only version bump with no direct code changes in this repo; risk is limited to any upstream behavioral changes in the TRON snap affecting TRON-specific flows. > > **Overview** > Bumps `@metamask/tron-wallet-snap` from `1.24.0` to `^1.25.0` in `package.json`, updating the resolved version to `1.25.0` in `yarn.lock`. > > No application code changes; this is a dependency-only update intended to pick up upstream fixes and behavior changes in the TRON snap. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 0a08885. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->
## **Description**
Added new scenario attributes to Sentry:
- Browserstack recording link
- Github action link
- Scenario team owner
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry:
## **Related issues**
Fixes:
## **Manual testing steps**
```gherkin
Feature: my feature name
Scenario: user [verb for user action]
Given [describe expected initial app state]
When user [verb for user action]
Then [describe expected outcome]
```
## **Screenshots/Recordings**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
- [ ] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
## **Pre-merge reviewer checklist**
- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Adds new external BrowserStack API calls and extra metadata to Sentry
transaction payloads during test teardown, which could impact reporting
or introduce intermittent failures if env/config changes. Core app logic
is unaffected.
>
> **Overview**
> E2E performance runs now publish richer Sentry transactions by
**mirroring key scenario attributes**
(project/provider/team/status/retry/build variant/device/file path) into
both Sentry `tags` and each step `span.data` for easier filtering and
correlation.
>
> The performance fixture now optionally fetches and attaches a
**BrowserStack session recording URL** (derived from the test
`sessionId` annotation and BrowserStack session details) and the Sentry
publisher also includes **GitHub Actions run/job metadata** (from
`GITHUB_*` env vars) in `extra` and span data.
>
> Tests were updated to cover the new payload fields and to manage the
additional GitHub env vars during setup/teardown.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
8b2546d. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
![https://cursor.com/assets/images/open-in-web-dark.png"><source](https://cursor.com/assets/images/open-in-web-dark.png"><source){kind=link}
![https://cursor.com/assets/images/open-in-web-light.png"><img](https://cursor.com/assets/images/open-in-web-light.png"><img){kind=link}
![https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a](https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a){kind=link}
![https://cursor.com/assets/images/open-in-cursor-dark.png"><source](https://cursor.com/assets/images/open-in-cursor-dark.png"><source){kind=link}
![https://cursor.com/assets/images/open-in-cursor-light.png"><img](https://cursor.com/assets/images/open-in-cursor-light.png"><img){kind=link}
![https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div](https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div){kind=link}
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.
8 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 : )