chore(runway): cherry-pick fix: check chainRanking against ALLOWED_BRIDGE_CHAIN_IDS#25809
Merged
joaoloureirop merged 3 commits intorelease/7.65.0from Feb 9, 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.
-->
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?
-->
<!--
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
Fixes:
```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]
```
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
<!-- [screenshots/recordings] -->
<!-- [screenshots/recordings] -->
- [ ] 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.
- [ ] 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**
> Narrow change to selector filtering logic with comprehensive unit test
coverage; main risk is unintentionally hiding a chain if allowlist/CAIP
formatting is incorrect.
>
> **Overview**
> Prevents *forward-incompatible* networks from being surfaced when the
remote `bridgeConfigV2.chainRanking` feature flag adds new chains that
older clients don’t support.
>
> Adds a shared `isAllowedBridgeChainId` guard and applies it to
`selectSourceChainRanking`, `selectDestChainRanking`, and
`selectIsBridgeEnabledSourceFactory` so only allowlisted EVM/non-EVM
CAIP chain IDs are considered. Updates/adds unit tests to cover
allowlist filtering for source/dest ranking and source-enabled checks.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
93e1367. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| bridgeFeatureFlags.chains[caipChainId]?.isActiveSrc | ||
| return bridgeFeatureFlags.chainRanking?.some( | ||
| (chain) => | ||
| chain.chainId === caipChainId && isAllowedBridgeChainId(chain.chainId), |
There was a problem hiding this comment.
Source bridge check drops support flag and isActiveSrc
High Severity
selectIsBridgeEnabledSourceFactory was rewritten to only check chainRanking presence and isAllowedBridgeChainId, but it no longer checks bridgeFeatureFlags.support (global kill switch) or isActiveSrc (per-chain source flag). This means bridge appears enabled as source even when globally disabled or when a chain's source is deactivated. selectIsBridgeEnabledDest still checks both support and isActiveDest, creating an asymmetry. Downstream, selectIsSwapsLive (source OR dest) will return true even when support is false, breaking the remote kill switch.
Additional Locations (1)
joaoloureirop
approved these changes
Feb 6, 2026
joaoloureirop
added
the
skip-sonar-cloud
Contributor
🔍 Smart E2E Test Selection⏭️ Smart E2E selection skipped - base branch is not main (base: release/7.65.0) All E2E tests pre-selected. |
|
joaoloureirop
approved these changes
Feb 9, 2026
metamaskbot
added
the
release-7.65.0
Collaborator
|
No release label on PR. Adding release label release-7.65.0 on PR, as PR was cherry-picked in branch 7.65.0. |
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.
3 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.
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.
Changelog
CHANGELOG entry: null
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Docs and MetaMask Mobile
Coding
Standards.
if applicable
guidelines).
Not required for external contributors.
Pre-merge reviewer checklist
app, test code being changed).
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.
Note
Medium Risk
Changes the source-chain enablement logic and filters chain lists based on an allowlist, which can affect which networks appear/are selectable in bridge/swap flows; scope is contained to selectors with added test coverage.
Overview
Adds client-side allowlist filtering (
ALLOWED_BRIDGE_CHAIN_IDS) for chains coming from the remotechainRankingflag to prevent unsupported future networks from being surfaced.selectSourceChainRankingandselectDestChainRankingnow drop non-allowed CAIP chain IDs (with EVM CAIP IDs normalized to hex for allowlist checks), andselectIsBridgeEnabledSourceFactoryswitches to treating source enablement as presence in allowedchainRankingrather thansupport/isActiveSrcflags. Tests are updated/expanded to cover the new filtering behavior and the revised source-enabled semantics.Written by Cursor Bugbot for commit 71b3e9a. This will update automatically on new commits. Configure here.
2726418