fix: cp-7.77.0 cp-7.78.0 missing metamask pay transactions in activity

[matthewwalsh0]

Description

The Activity tab had several bugs causing MetaMask Pay transactions to be missing, duplicated, or unreachable from the source chain. This PR addresses four root causes in production code plus a test alignment for the bridge smoke E2E:

1. Source-chain visibility. Submitted EVM transactions were filtered strictly by tx.chainId, so a MetaMask Pay parent was only visible on its destination chain. The source chain is recorded on metamaskPay.chainId (for gasless flows) or on linked child transactions via requiredTransactionIds (for non-gasless flows). A new selectRelatedChainIdsByTransactionId selector returns the full set of chain IDs a transaction relates to, and the Activity list now matches against that set.

2. Dedupe fallback collapsed internal MetaMask Pay transactions. When a transaction had no nonce, selectLocalTransactions fell back to txParams.actionId as the dedupe key. actionId is a top-level field on TransactionMeta, not on txParams, so for MetaMask Pay internal transactions (which have no nonce) every entry collapsed onto the same undefined key and all but one were dropped. The fallback now uses the top-level id, which is always present.

3. Local transactions were scoped to the wrong account. selectLocalTransactions gated on selectEvmAddress — the EVM address of the currently selected internal account. When the user picked a non-EVM account (e.g. Solana), this was undefined and the selector returned an empty list. Switching to "All popular networks" did not restore the address because that toggle changes enabled networks, not the selected account. It now uses selectSelectedAccountGroupEvmInternalAccount, the same source already used by the Activity tab's API query.

4. Incoming-transaction duplicates. The TransactionController incoming-transactions feature stores incoming transfers as separate TransactionMeta entries marked with isTransfer !== undefined. The accounts API also returns these transactions in its confirmed history, producing duplicate rows in the Activity tab. The dedupe step now skips entries with isTransfer !== undefined, leaving the accounts-API row as the canonical source.

5. Bridge smoke E2E row alignment. The Activity list merges pending smart transactions in alongside the real TransactionMeta row, producing a stale shell entry that lands at row 0. bridge-action-smoke was asserting on row 0 and timing out. The test now asserts on row 1, with a TODO to remove the STX-state merge from the Activity selectors and restore row 0.

Changelog

CHANGELOG entry: Fixed MetaMask Pay transactions appearing duplicated or missing from the Activity tab, including on the source chain and when the selected account is non-EVM.

Related issues

Fixes: #30066

Manual testing steps

Feature: MetaMask Pay Activity visibility

  Scenario: User views Activity on the chain that funded a MetaMask Pay transaction
    Given the user has completed a MetaMask Pay transaction funded by a token on chain X with destination chain Y
    And both chains X and Y are enabled networks

    When the user opens the Activity tab with chain X selected
    Then the MetaMask Pay transaction is visible in the list

    When the user opens the Activity tab with chain Y selected
    Then the MetaMask Pay transaction is also visible in the list

  Scenario: User views Activity after switching to a non-EVM account
    Given the user has pending MetaMask Pay transactions visible in the Activity tab

    When the user switches to a non-EVM account in the same account group
    And switches back to "All popular networks"
    Then the pending MetaMask Pay transactions remain visible

  Scenario: User views a single on-chain MetaMask Pay transaction
    Given the user has completed a single-chain MetaMask Pay transaction (for example an mUSD conversion)

    When the user opens the Activity tab
    Then the transaction appears exactly once

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• 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 format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
• I've tested with a power user scenario
• I've instrumented key operations with Sentry traces for production performance metrics

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.

---

Note

^{Cursor Bugbot is generating a summary for commit f45d17e. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c656d63. Configure here.}

[matthewwalsh0]

@n3ps This is a release blocker and cherry-pick so I'm intentionally limiting the scope here, but two points for potential future refactor:

• We shouldn't need to query smart transactions at all for the activity. Originally, they were also created directly by swaps and therefore could bypass the TransactionController, but for some time now all smart transactions are created via the TransactionController so we have a single source of truth for local state.
• Since we've switched to Accounts API polling in the client, we can entirely disable the legacy incoming transactions here, and remove any calls to updateIncomingTransactions. This should reduce local state size, and redundant calls to Accounts API.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeSwap, SmokeConfirmations, SmokeWalletPlatform
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 88%

click to see 🤖 AI reasoning details

E2E Test Selection:

The changes in this PR affect transaction history display and filtering logic in several important ways:

1. selectLocalTransactions selector changes: Now uses selectSelectedAccountGroupEvmInternalAccount (multi-SRP group EVM account) with fallback to selectEvmAddress. Also adds filtering of isTransfer transactions (incoming transfers from TransactionController). This directly affects what transactions appear in the activity/history view.

2. New selectRelatedChainIdsByTransactionId selector: Maps transaction IDs to all related chain IDs (own chain + MetaMask Pay chain + child transaction chains). Used in UnifiedTransactionsView to fix filtering of bridge/cross-chain transactions so they appear even when only one of the related chains is enabled.

3. UnifiedTransactionsView.tsx: Now uses relatedChainIdsByTransactionId to determine if a transaction should be shown based on any of its related chain IDs being enabled, rather than just the transaction's own chain ID. This is critical for bridge transactions.

4. bridge-action-smoke.spec.ts: Directly updated to reflect the new row ordering (BRIDGE_ROW = 1 instead of 0) because a stale STX entry now appears at row 0 due to the selectLocalTransactions changes.

Tags selected:

• SmokeSwap: The bridge test was directly modified, and the chain ID filtering in UnifiedTransactionsView affects bridge transaction display. Bridge is a core swap/bridge flow.
• SmokeConfirmations: Per tag description, when selecting SmokeSwap, also select SmokeConfirmations as transaction confirmations are part of the swap/bridge flow.
• SmokeWalletPlatform: Transaction history display (incoming/outgoing ETH transactions, token transfer details) is directly affected by the isTransfer filtering change and the multi-SRP account group selector change. The incoming-transactions.spec.ts test uses UnifiedTransactionsView and is tagged SmokeWalletPlatform.

Tags NOT selected:

• SmokeAccounts: The multi-SRP selector change is used for address resolution in transaction filtering, not for account management UI flows directly.
• SmokeIdentity: No sync/profile sync changes.
• SmokeNetworkAbstractions/SmokeNetworkExpansion: The chain ID filtering change is internal to transaction display, not network management UI.
• SmokeStake/SmokeMoney/SmokePerps: No direct changes to these flows.

Performance Test Selection:
The changes are to transaction selectors and filtering logic (memoized with createSelector/createDeepEqualSelector), and a UI component that uses these selectors. While there are new selectors added, they use standard memoization patterns and the changes are incremental. The UnifiedTransactionsView change adds one additional useSelector call with a memoized selector. These changes are unlikely to cause measurable performance regressions in the performance test scenarios (account list, onboarding, login, swaps, launch, asset loading). No performance test tags are warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
97.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud