Description

This branch refreshes card home data and Baanx configuration when remote card feature flags change, and fixes a race where a slow unauthenticated fetchCardHomeData could overwrite state after successful submitCredentials.

Feature flags

• app/selectors/featureFlagController/card/index.ts: exports defaultCardFeatureFlag and resolveCardFeatureFlag (empty remote payload → defaults). selectCardFeatureFlag now uses resolveCardFeatureFlag so the same resolution rules apply in Redux selectors and Engine.

BaanxProvider / init

• BaanxProvider.ts: accepts optional getCardFeatureFlag (lazy) in addition to legacy cardFeatureFlag. A private getter resolves cardFeatureFlag on each read so URLs/constants track the latest remote flags without recreating the provider.
• card-controller/index.ts: passes getCardFeatureFlag from RemoteFeatureFlagController:getState + resolveCardFeatureFlag into BaanxProvider.

CardController

• Subscribes to RemoteFeatureFlagController:stateChange with a selector that serializes remoteFeatureFlags.cardFeature so only meaningful card-flag updates run the handler.
• #handleCardFeatureFlagChange: if an EVM address is selected, invalidateFetch(), clears cardHomeData / sets cardHomeDataStatus to idle, then refetches card home data.
• #fetchCardHomeDataWithLogging: centralizes fetchCardHomeData + Logger.error for account switch, feature-flag refresh, submitCredentials, and validateAndRefreshSession.
• #triggerCardholderCheck (accounts API URL path): uses resolveCardFeatureFlag instead of ad-hoc casting.
• submitCredentials: sets cardHomeData to null and status idle, calls invalidateFetch(), then fetches—so in-flight unauthenticated responses cannot win over authenticated data.

Messenger / types

• card-controller-messenger/index.ts: allows event RemoteFeatureFlagController:stateChange.
• types.ts: CardControllerAllowedEvents includes RemoteFeatureFlagControllerStateChangeEvent.

Tests

• CardController.test.ts: subscription to remote feature-flag state; handler clears state and refetches; drops in-flight unauthenticated card home data after successful auth.
• BaanxProvider.test.ts: getCardFeatureFlag read lazily during getOnChainAssets.

Changelog

CHANGELOG entry: Card — CardController listens for RemoteFeatureFlagController:stateChange and refetches card home data when cardFeature changes; BaanxProvider resolves card feature flags lazily; shared resolveCardFeatureFlag; submitCredentials invalidates in-flight fetches and resets card home state to avoid stale unauthenticated data after login.

Related issues

Fixes: #29348

Manual testing steps

Feature: Card home and Baanx flags stay in sync with remote card feature flags

  Scenario: Remote card feature flag updates while card tab is open
    Given the user is on an EVM account with card session and card home loaded
    When remote `cardFeature` changes (e.g. rollout or config update)
    Then card home data is cleared to idle and refetched
    And Baanx-backed calls use the updated flag-derived config on subsequent requests

  Scenario: Login while an unauthenticated card home fetch is still in flight
    Given an unauthenticated card home fetch has not completed
    When the user completes submitCredentials successfully
    Then authenticated card home data wins and a late unauthenticated response does not overwrite it

  Scenario: Card feature flag change with no selected EVM address
    When RemoteFeatureFlagController emits a card-related change but no EVM address is selected
    Then the handler returns early without refetch errors

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
  • 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.