fix(pay): always emit mm_pay_payment_token_list_size on confirmation events

[jpuri]

Description

1. Move mm_pay_payment_token_list_size outside the if(payToken) guard so it is written regardless of whether a payment token was selected.
2. Fix: mm_pay_payment_method_selected missing on 18.5% of Transaction Finalized events for money_account_deposit

Changelog

CHANGELOG entry:

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1636
Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1634

Manual testing steps

NA

Screenshots/Recordings

NA

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
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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

Low Risk
Changes are limited to analytics property assembly and UI metric hooks; no payment execution or auth paths are modified.

Overview
MetaMask Pay confirmation and finalized-transaction analytics are tightened so key properties are present even when the user has not picked a pay token or when controller metadata is incomplete.

On the confirmation UI hook, mm_pay_payment_token_list_size is now set whenever payment-method metrics are updated (alongside mm_pay_payment_method_available), instead of only when a pay token is already selected. Tests assert list sizes of 5 and 0 in the scenarios that previously omitted the field.

In addPayTypeProperties (transaction-controller metrics), baseline mm_pay, mm_pay_payment_method_selected, and mm_pay_use_case are derived for recognized Pay transaction types even when metamaskPay lacks both chainId and tokenAddress, with optional mm_pay_chain_selected / mm_pay_token_selected from controller state or token lookup. Non–Pay-type transactions still emit no Pay properties unless full metamaskPay metadata is present. This addresses missing mm_pay_payment_method_selected on a slice of Transaction Finalized events (e.g. money_account_deposit).

^{Reviewed by Cursor Bugbot for commit 1ef0205. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

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.

[github-actions]

🧪 Flaky unit test detection

Run history flaky detection

View recent run history

Historical failure rate is a hint, not proof — review each suggestion in context. See the flaky-test-detection skill for the full pattern reference and manual audit workflow.

Failures / runs sampled per window:

File	7d	15d	30d
app/components/Views/confirmations/hooks/pay/useTransactionPayMetrics.test.ts	0/146	0/197	0/305

AI-detected flaky patterns

app/components/Views/confirmations/hooks/pay/useTransactionPayMetrics.test.ts

• J6 — Arbitrary setTimeout/sleep used as a synchronization barrier (high)
  • This test (and ~20 similar tests in the file) relies on await act(async () => noop()) immediately after runHook() (which invokes renderHookWithProvider) to act as a synchronization barrier. This allows time for the hook's internal useEffect (which calls updateConfirmationMetric) to execute before the assertion. This is exactly the zero-delay flush anti-pattern highlighted in J6 (see skill: even setTimeout(resolve, 0) is non-deterministic under CI load). The beforeEach correctly uses jest.resetAllMocks(), no waitFor is present, no fake timers, no module-level lets, and no spyOn without restore. The second test file uses proper mocking of Date.now with restoreAllMocks in afterEach and has no J1-J10 violations. Historical data shows zero failures for both files so hint not used. This pattern risks intermittent CI failures when effect timing varies.
  • Suggested fix in app/components/Views/confirmations/hooks/pay/useTransactionPayMetrics.test.ts:

    -    runHook();
    -
    -    await act(async () => noop());
    -
    -    expect(updateConfirmationMetricMock).toHaveBeenCalledWith({
    -      id: transactionIdMock,
    -      params: {
    -        properties: {
    -          mm_pay_payment_method_available: ['crypto'],
    -          mm_pay_payment_token_list_size: 5,
    -        },
    -        sensitiveProperties: {},
    -      },
    -    });
    -  });
    -
    +    runHook();
    +
    +    await waitFor(() => {
    +      expect(updateConfirmationMetricMock).toHaveBeenCalledWith({
    +        id: transactionIdMock,
    +        params: {
    +          properties: {
    +            mm_pay_payment_method_available: ['crypto'],
    +            mm_pay_payment_token_list_size: 5,
    +          },
    +          sensitiveProperties: {},
    +        },
    +      });
    +    });
    +  });
    +

This check is informational only and does not block merging.

[matthewwalsh0]

Rather than duplicating lots of identical logic, could we support this inline above by removing the early return?

[jpuri]

PR is updated to address this.

[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 f5e3701. Configure here.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeConfirmations, SmokePerps, SmokePredictions, SmokeMoney
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 82%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are confined to analytics/metrics tracking for MetaMask Pay flows:

1. metamask-pay.ts: Fixes metrics property collection logic for PAY_TYPE transactions. Key changes:

   • Early return guard if mm_pay already set (prevents duplicate processing)
   • PAY_TYPE transactions (perpsDeposit, predictWithdraw, moneyAccountDeposit, moneyAccountWithdraw) now get baseline metrics even without metamaskPay.chainId/tokenAddress
   • Null-safe state access
   • Conditional property assignment for mm_pay_chain_selected and mm_pay_token_selected

2. useTransactionPayMetrics.ts: Moves mm_pay_payment_token_list_size outside a conditional block so it's always included in analytics events regardless of payment method state.

These are metrics-only changes with no impact on transaction execution, UI rendering, or user-facing behavior. However, they affect the analytics events fired during:

• Transaction confirmations (SmokeConfirmations) - the core confirmation flow
• Perps deposit flows (SmokePerps)
• Predictions deposit/withdraw flows (SmokePredictions)
• Money account deposit/withdraw flows (SmokeMoney)

Per tag descriptions: SmokePerps, SmokePredictions, and SmokeMoney all require SmokeConfirmations (on-chain transactions). SmokePerps also requires SmokeWalletPlatform (Trending section). SmokePredictions also requires SmokeWalletPlatform.

Risk is LOW because:

• No functional logic changes, only metrics collection
• Changes are additive (more data collected, not less)
• Unit tests updated to verify new behavior
• No shared components (TabBar, navigation, modals) affected

Performance Test Selection:
The changes are purely analytics/metrics tracking modifications with no impact on rendering performance, asset loading, app launch, or any performance-sensitive flows. 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
92.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud