Description

Fixes an issue where the marketing_consent notification pre-prompt could be re-triggered during the same app session after the user turned marketing consent off in Settings.

The pre-prompt is intended to behave as a startup flow. This change latches the marketing consent value used for startup prompt resolution, so once startup eligibility has resolved, later Redux updates from user actions do not cause the prompt to appear unexpectedly.

Social-login marketing consent backfill is still respected as part of startup resolution. If backfill is pending, the prompt waits for it to clear, then decides once using the resolved consent value.

Risk
Low risk.

This change is scoped to usePushPrePromptVariant, which only decides which notification pre-prompt variant to show. It does not change notification registration, OS permission requests, Settings behavior, analytics opt-in/out behavior, or persisted storage keys.

The change preserves existing behavior for the main paths:

Users without OS push permission still resolve to the push permission prompt first.
Users who already saw the pre-prompt remain suppressed by PUSH_PRE_PROMPT_SHOWN.
Users with marketing consent enabled do not see the marketing consent prompt.
Users with marketing consent disabled at startup can still see the one-time startup prompt if otherwise eligible.
Social-login users still wait for marketing consent backfill before the marketing prompt decision is made.
The risk is low because the fix narrows when the marketing consent prompt can appear rather than expanding eligibility. The only behavior removed is the unintended mid-session re-trigger after Settings opt-out.

Changelog

CHANGELOG entry: Fixed an issue where the marketing consent notification pre-prompt could reappear after turning marketing consent off in Settings.

Related issues

Fixes:

Manual testing steps

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]

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.