Description

This PR makes the E2E remote feature-flag mock deterministic for the homepage
trending-sections A/B test.

The flaky behavior came from setupRemoteFeatureFlagsMock(mockServer, {})
serving the production registry defaults. For
homeTMCU470AbtestTrendingSections, the production default is a percentage
rollout array, not a fixed control value. RemoteFeatureFlagController
resolves that rollout at runtime using a deterministic threshold based on:

sha256(analyticsId + flagName)

That means the same build and the same mocked feature-flag endpoint can still
render different homepage UI if the runtime analytics ID differs:

• control renders the regular Perpetuals section.
• trendingSections renders the separate Trending perpetuals section.

The fix pins homeTMCU470AbtestTrendingSections to control in the shared
E2E-safe mock defaults. Individual tests can still explicitly opt into
trendingSections by passing an override to createRemoteFeatureFlagsMock or
setupRemoteFeatureFlagsMock.

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: E2E remote feature flag defaults

  Scenario: homepage trending sections A/B test is deterministic in E2E mocks
    Given the E2E remote feature flag mock is created with default overrides
    When the mock response is generated
    Then homeTMCU470AbtestTrendingSections resolves to control

  Scenario: a test intentionally opts into the treatment
    Given the E2E remote feature flag mock is created with a trendingSections override
    When the mock response is generated
    Then homeTMCU470AbtestTrendingSections resolves to trendingSections

Verified with:

NODE_OPTIONS=--max-old-space-size=8192 yarn jest tests/api-mocking/helpers/remoteFeatureFlagsHelper.test.ts --runInBand --watchman=false --forceExit

Result: 1 test suite passed, 23 tests passed.

Screenshots/Recordings

Not applicable. Test-only change.

Before

E2E default feature-flag mocks could return the production rollout array for
homeTMCU470AbtestTrendingSections, allowing runtime analytics ID bucketing to
choose either homepage variant.

After

E2E default feature-flag mocks pin homeTMCU470AbtestTrendingSections to
control, so existing specs continue to see the Perpetuals section unless a
spec explicitly overrides the variant.

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.