[pull] main from MetaMask:main#513
Merged
Merged
Conversation
## Summary This PR syncs the latest changes from `stable` into `release/7.64.1`. ## Why is this needed? A release branch (`release/7.64.0`) was merged into `stable`. This PR brings those changes (hotfixes, etc.) into `release/7.64.1`. ## Action Required **Please review and resolve any merge conflicts manually.** If there are conflicts, they will appear in this PR. Resolve them to ensure the release branch has all the latest fixes from stable. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only change to the changelog with no runtime or behavioral impact. > > **Overview** > Updates `CHANGELOG.md` for `7.64.0` by adding an entry noting the CardHome button color change (`#25737`). > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 13e2756. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: João Loureiro <175489935+joaoloureirop@users.noreply.github.com>
…IDGE_CHAIN_IDS (#25808) - fix: check chainRanking against ALLOWED_BRIDGE_CHAIN_IDS (#25788) <!-- 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** When new networks are added to the chainRanking remote feature flag in LaunchDarkly, older app versions that don't support those networks would still surface them in the UI (destination network pills, source chain checks). This creates a forward-compatibility gap where users could see unsupported networks. This change adds client-side filtering of chainRanking against ALLOWED_BRIDGE_CHAIN_IDS — the hardcoded allowlist in @metamask/bridge-controller that defines which chains this version of the client actually supports. This ensures that chains added to the remote flag in the future are silently ignored by older app versions that lack support for them. <!-- 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: ## **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** > Touches bridge network selection/enablement selectors, so a mistake could hide valid networks or incorrectly disable bridging, but the change is narrow and well-covered by unit tests. > > **Overview** > Adds a client-side allowlist check (`isAllowedBridgeChainId`) so `chainRanking` entries are filtered against `ALLOWED_BRIDGE_CHAIN_IDS` before being surfaced. > > `selectSourceChainRanking` now filters by *both* supported chains and user-configured networks, `selectDestChainRanking` filters to supported chains only, and `selectIsBridgeEnabledSourceFactory` now treats a source chain as enabled only if it exists in the filtered `chainRanking`. Tests are expanded to cover EVM/non-EVM unsupported chains and the new source/dest filtering behavior. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 557c0e3. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> [2726418](2726418) Co-authored-by: Bryan Fullam <bryan.fullam@consensys.net>
<!-- 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** **Reason for change:** `yarn audit:ci` was failing due to a high-severity vulnerability in `axios` (GHSA-43fc-jf86-j433): Denial of Service via the `__proto__` key in `mergeConfig`. Affected versions are ≤1.13.4; the project was on 1.12.2. **Solution:** - Bumped axios resolutions to `^1.13.5` in root `package.json` (both resolution entries) and in `.github/scripts/package.json`. - Added `axios` to `npmPreapprovedPackages` in `.yarnrc.yml` so Yarn’s 3-day minimal age gate allows the new release. - Ran `yarn install --no-immutable` to update the lockfile to axios 1.13.5. No code changes; dependency upgrade only. `yarn audit:ci` now passes. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: N/A ## **Manual testing steps** ```gherkin Feature: Security audit and dependency usage after axios upgrade Scenario: CI audit passes after axios upgrade Given the repo has axios resolved to 1.13.5 When I run yarn audit:ci Then the command exits with code 0 and reports no audit suggestions Scenario: App and scripts still run with upgraded axios Given the branch is checked out and dependencies are installed When I run yarn install and then run any flow that uses axios (e.g. scripts or app network calls) Then no runtime errors occur and behavior is unchanged ``` ## **Screenshots/Recordings** Not applicable (dependency-only change; no UI changes). ### **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). - [x] 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** > Dependency upgrade plus bundler resolution changes could affect runtime networking behavior or Metro module resolution, especially if any code relied on Axios’ Node build. > > **Overview** > Bumps `axios` to `^1.13.5` (and updates both root `yarn.lock` and `.github/scripts/yarn.lock`) to address the reported security advisory. > > Updates `metro.config.js` resolver logic to always redirect `axios` (and `axios/dist/node/*`) imports to `axios/dist/browser/axios.cjs`, while preserving the existing E2E-only Sentry module mocking behavior under the new unified `resolveRequest` handler. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 520829a. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: sethkfman <10342624+sethkfman@users.noreply.github.com> Co-authored-by: Mark Stacey <markjstacey@gmail.com> Co-authored-by: Cal-L <cal.leung@consensys.net>
# 🚀 v7.64.1 Testing & Release Quality Process Hi Team, As part of our new **MetaMask Release Quality Process**, here’s a quick overview of the key processes, testing strategies, and milestones to ensure a smooth and high-quality deployment. --- ## 📋 Key Processes ### Testing Strategy - **Developer Teams:** Conduct regression and exploratory testing for your functional areas, including automated and manual tests for critical workflows. - **QA Team:** Focus on exploratory testing across the wallet, prioritize high-impact areas, and triage any Sentry errors found during testing. - **Customer Success Team:** Validate new functionalities and provide feedback to support release monitoring. ### GitHub Signoff - Each team must **sign off on the Release Candidate (RC)** via GitHub by the end of the validation timeline (**Tuesday EOD PT**). - Ensure all tests outlined in the Testing Plan are executed, and any identified issues are addressed. ### Issue Resolution - **Resolve all Release Blockers** (Sev0 and Sev1) by **Tuesday EOD PT**. - For unresolved blockers, PRs may be reverted, or feature flags disabled to maintain release quality and timelines. ### Cherry-Picking Criteria - Only **critical fixes** meeting outlined criteria will be cherry-picked. - Developers must ensure these fixes are thoroughly reviewed, tested, and merged by **Tuesday EOD PT**. --- ## 🗓️ Timeline and Milestones 1. **Today (Friday):** Begin Release Candidate validation. 2. **Tuesday EOD PT:** Finalize RC with all fixes and cherry-picks. 3. **Wednesday:** Buffer day for final checks. 4. **Thursday:** Submit release to app stores and begin rollout to 1% of users. 5. **Monday:** Scale deployment to 10%. 6. **Tuesday:** Full rollout to 100%. --- ## ✅ Signoff Checklist Each team is responsible for signing off via GitHub. Use the checkbox below to track signoff completion: # Team sign-off checklist - [ ] Mobile Platform This process is a major step forward in ensuring release stability and quality. Let’s stay aligned and make this release a success! 🚀 Feel free to reach out if you have questions or need clarification. Many thanks in advance # Reference - Testing plan sheet - https://docs.google.com/spreadsheets/d/1tsoodlAlyvEUpkkcNcbZ4PM9HuC9cEM80RZeoVv5OCQ/edit?gid=404070372#gid=404070372
## **Description**
The region eligibility API (`/regions/countries/{region}`) was logging
errors to Sentry via `Logger.error` for every non-OK response (403, 404,
5xx), generating **16k Sentry events from 3.4k users** over 2 months.
These are API-side concerns, not FE bugs:
- **403**: User's IP blocked by Cloudflare/WAF (VPN, sanctions, bot
detection)
- **404**: Region code not in the eligibility dataset (e.g. Kosovo `XK`,
bare `US`/`CA` without state)
- **5xx**: API-side outage — the API team should monitor this, not the
FE
**Change:** Remove `Logger.error` from the catch block so these expected
failures stop flooding Sentry. The existing `ERROR` routing and
user-facing "Eligibility check failed" message remain unchanged.
## **Changelog**
CHANGELOG entry: null
## **Related issues**
Refs: https://metamask.sentry.io/issues/7034541328/
Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3246
## **Manual testing steps**
```gherkin
Feature: Ramp region eligibility error handling
Scenario: user in a supported region opens buy flow
Given the user's geolocation returns a valid region (e.g. US-TX, GB, DE)
When user taps "Buy" on the wallet screen
Then the existing routing logic (deposit vs aggregator) works as before
Scenario: user in an unsupported region opens buy flow
Given the eligibility API returns a non-OK response (403, 404, etc.)
When user taps "Buy" on the wallet screen
Then user sees "Eligibility check failed" modal (same as before)
And no error is logged to Sentry
```
## **Screenshots/Recordings**
### **Before**
N/A — no UI changes. The user-facing behavior is identical before and
after this change.
### **After**
N/A — same user-facing behavior. The only difference is that errors are
no longer logged to Sentry.
## **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**
> Removes only error logging and does not change routing decisions or
data handling; primary risk is reduced observability for unexpected
client-side failures.
>
> **Overview**
> Stops logging ramp region eligibility fetch failures in
`useRampsSmartRouting` by removing `Logger.error` from the `catch` path.
>
> The hook still falls back to `UnifiedRampRoutingType.ERROR` on any
exception/non-OK response, but these expected API-side failures will no
longer generate Sentry noise.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
303924d. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Co-authored-by: Cursor <cursoragent@cursor.com>
This PR syncs the stable branch to main for version 7.66.0. *Synchronization Process:* - Fetches the latest changes from the remote repository - Resets the branch to match the stable branch - Attempts to merge changes from main into the branch - Handles merge conflicts if they occur *File Preservation:* Preserves specific files from the stable branch: - CHANGELOG.md - bitrise.yml - android/app/build.gradle - ios/MetaMask.xcodeproj/project.pbxproj - package.json Indicates the next version candidate of main to 7.66.0 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only changes to the changelog and version compare links; no runtime code is affected. > > **Overview** > Adds a new `7.64.1` section to `CHANGELOG.md` documenting a fix for validating `chainRanking` against `ALLOWED_BRIDGE_CHAIN_IDS`. > > Also corrects a formatting issue in the `7.63.1` section (removes a stray line and normalizes the Perps reconnect entry) and updates the compare links at the bottom so `Unreleased` now points to `v7.64.1` and includes a new `7.64.1` tag link. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 2102d66. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** The `useDetectGeolocation` hook was throwing and reporting **all** non-ok HTTP responses (e.g. 502 Bad Gateway) to Sentry via `Logger.error`, generating **64k+ events** for server-side issues not actionable by the mobile client. **Root causes addressed:** 1. **Sentry noise**: The hook threw an error on any non-ok HTTP response, which was then caught and sent to Sentry. HTTP error responses (502, 404, etc.) are server-side issues — the mobile client cannot fix them, so they should not be reported as app errors. 2. **Unhelpful error message**: The error used `response.statusText` which is always empty under HTTP/2, producing `"Network response was not ok: "` with no diagnostic value. **What changed:** - Non-ok HTTP responses now return early instead of throwing — no Sentry report - Genuine client-side exceptions (network failures, parsing errors) are still reported to Sentry via `Logger.error` for platform team visibility - Added explicit `void` return type to the hook - Updated tests to verify the correct error handling behaviour - Fixed typo in test describe block (`useDetecGeolocation` → `useDetectGeolocation`) **User-facing impact:** When the geolocation endpoint returns an HTTP error, `detectedGeolocation` remains `undefined` in Redux. This triggers the existing fallback flow: `useRampsSmartRouting` sets `rampRoutingDecision` to `ERROR`, and `useRampNavigation.goToBuy()` intercepts navigation to show the **EligibilityFailedModal** instead of the token selection screen. This behaviour is unchanged — users already see this modal when geolocation fails. The only difference is that these server-side HTTP errors are no longer flooding Sentry. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3254 Refs: https://metamask.sentry.io/issues/7034541328/ ## **Manual testing steps** ```gherkin Feature: Geolocation detection on Ramp Scenario: user opens the Ramp flow when geolocation endpoint is healthy Given the geolocation API returns a valid country code When user navigates to Buy/Sell Then the detected geolocation is stored in Redux state Scenario: user opens the Ramp flow when geolocation endpoint returns an HTTP error Given the geolocation API returns a 502 Bad Gateway When user navigates to Buy/Sell Then no error is reported to Sentry And the user sees the EligibilityFailedModal with "Contact Support" and "Got it" buttons Scenario: user opens the Ramp flow when network is unavailable Given the device has no network connectivity When user navigates to Buy/Sell Then the network error is reported to Sentry for platform team visibility And the user sees the EligibilityFailedModal with "Contact Support" and "Got it" buttons ``` ## **Screenshots/Recordings** ### **Before** Not applicable (no UI changes) ### **After** Not applicable (no UI changes) ## **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** > Small, localized change to error-handling in `useDetectGeolocation` with updated unit tests; main risk is silently ignoring HTTP error responses if downstream expects a dispatched failure state. > > **Overview** > Geolocation detection no longer throws/logs when the geolocation endpoint returns a non-OK HTTP response; it now returns early, avoiding noisy Sentry reports for server-side failures. > > Client-side exceptions (e.g., network failures or `response.text()` errors) are still reported via `Logger.error`, the hook now has an explicit `void` return type, and tests were updated to reflect the new behavior (including fixing a `useDetecGeolocation` typo and removing edge-case error tests that no longer apply). > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit cbe7620. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Cursor <cursoragent@cursor.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.
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 : )