fix(deposit): hydrate provider token on Deposit root entry cp-7.72.0

[wachunei]

Description

Deposit Root previously called checkExistingToken() only when a fiat order in CREATED state existed in Redux. If the user had completed Verify / Email / OTP and stored a provider token, then closed Deposit and reopened it without an in-progress CREATED order, the vault was never read and isAuthenticated stayed false—so Build Quote sent them through the login flow again.

This change always runs checkExistingToken() (with the existing timeout) before branching to Build Quote, Enter Email, or Bank Details, so the stored token hydrates the SDK on every Deposit entry. initializeFlow is reorganized to match that order (guard → default auth → attempt vault read → finally mark token check complete → branch on createdOrder).

Changelog

CHANGELOG entry: Fixed Deposit prompting for login again after closing and reopening the flow when a stored session was still valid.

Related issues

Fixes:

Manual testing steps

Feature: Deposit session persists after closing and reopening

  Scenario: Continue deposit without repeating Verify / Email / OTP
    Given the user completed Deposit authentication (Verify, Email, OTP) and has a valid stored provider token
    And there is no in-progress deposit order in CREATED state
    When the user closes the Deposit flow and opens Deposit again
    And the user enters an amount and taps Continue on Build Quote
    Then the user is not sent to Verify / Email / OTP again
    And the post-quote flow proceeds as an authenticated user

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.

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

Medium Risk
Changes Deposit root initialization to always attempt stored-token hydration and to gate navigation decisions on that result, which can affect authentication and routing behavior. Adds re-entrancy guards to avoid duplicate async initialization, reducing race-condition risk but making flow control more complex.

Overview
Ensures Deposit Root always runs checkExistingToken() (with timeout/error handling) on entry before deciding whether to route to Build Quote, Enter Email, or Bank Details, fixing cases where users were re-prompted to authenticate despite a valid stored provider token.

Reworks initialization flow to be idempotent and single-flight via hasCheckedToken plus a new initializationInFlight guard, and updates the Root test to assert token hydration occurs even when there is no CREATED order before redirecting to BUILD_QUOTE.

^{Written by Cursor Bugbot for commit 513271a. This will update automatically on new commits. 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.

[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.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeRamps
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 90%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are scoped to app/components/UI/Ramp/Deposit/Views/Root/Root.tsx and its test file. The modification fixes a race condition in the Deposit flow initialization:

1. Race condition fix: Adds initializationInFlight ref to prevent duplicate checkExistingToken calls when the effect re-runs while the async operation is in flight.
2. Logic reorder: Previously, the code would skip checkExistingToken entirely when no created order existed (navigating to default route immediately). Now, checkExistingToken is always called first to hydrate the SDK/vault, and THEN the routing decision is made based on whether a created order exists.
3. Test update: Reflects the new behavior - checkExistingToken is now always called, even when no created order exists.

This is a behavioral change in the Deposit/Ramp flow initialization that could affect how users enter the deposit flow. The SmokeRamps tag covers fiat on-ramp/off-ramp features and is the appropriate tag to validate this change. No other features are impacted - the change is entirely contained within the Deposit Root component.

Performance Test Selection:
The changes are limited to initialization logic using React refs (no rendering changes, no list components, no state management changes that would affect performance). The fix prevents duplicate async calls which could marginally improve performance, but no performance test coverage is needed for this type of change.

View GitHub Actions results

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
17 value mismatches detected (expected — fixture represents an existing user).
View details

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud