[Due for payment 2026-05-11] [Due for payment 2026-05-07] [$250] Create Account - Unable to logged in with account if navigated to the app via Magic link

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.62-5
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176924/test-cases/41237540
Email or phone of affected tester (no customers): rybkina+041526@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 17 Pro /26.4.2
App Component: Other

Action Performed:

1. Launch app
2. Enter email Expensifail account which already exist.
3. Click on the Magic link received via email

Expected Result:

The user should navigated to the app and logged in with the new account

Actual Result:

Timer start from 0:00 for request a new code. Unable to login to with the account from Magic link.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049928401164710097
• Upwork Job ID: 2049928401164710097
• Last Price Increase: 2026-04-30

[melvin-bot]

Triggered auto assignment to @amyevans (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (Medium confidence)
Related Issues: None identified

Recommendation: NEEDS INVESTIGATION

PR #85234 is the most likely contributor to this regression given the scale of its navigation refactor and its changes to deep link URL processing, but cannot be confirmed without device-level reproduction. The PR author and approving reviewers should investigate whether the TAB_NAVIGATOR introduction affected magic link routing on iOS native.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach (approving reviewer) from highest-confidence causing PR only
Labels: DeployBlockerCash kept — there is an App PR that likely caused or contributed to this issue.

Detailed Analysis

Evidence

• The issue is iOS native only (staging, not production), and specifically involves the magic link login flow (v/:accountID/:validateCode route)
• The symptom is that after clicking the magic link, the user ends up on the validate code form with a 0:00 timer instead of being auto-logged in — this indicates the ValidateLoginPage either did not load or sign-in failed and the user was returned to the sign-in page
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 merged on 2026-04-24 is the largest navigation refactor in the staging deploy, touching 111 files including:
  • src/libs/Navigation/helpers/getAdaptedStateFromPath.ts — this function processes deep link URLs into navigation state; changes here could affect how the magic link URL is resolved to the ValidateLoginPage
  • src/libs/Navigation/linkingConfig/config.ts — all screen-to-URL mappings, though VALIDATE_LOGIN remains mapped at the root level
  • src/libs/Navigation/AppNavigator/AuthScreens.tsx — reworks the authenticated navigator structure around a new TAB_NAVIGATOR
  • iOS-specific navigator state files (useCustomRootStackNavigatorState/index.ios.ts) — introduces tab-awareness into iOS-specific navigation slicing logic
• The ValidateLoginPage is registered in PublicScreens.tsx and should be accessible by unauthenticated users. However, the new TAB_NAVIGATOR structure and changes to how navigation state is built from paths could cause the URL handler to navigate to the wrong screen or fail to dispatch the ValidateLoginPage correctly on iOS

Secondary Candidates (Low Confidence)

• PR Fix SLO on web #86416 ("Fix SLO on web") — Adds maybeCompleteAuthSession() from expo-web-browser to App.tsx. On native iOS this call is typically a no-op, but in edge cases it could interfere with URL session handling if the magic link URL is somehow treated as an OAuth redirect.
• PR Build full navigation state for stacked dynamic routes on refresh #87089 ("Build full navigation state for stacked dynamic routes on refresh") — Changes getAdaptedStateFromPath.ts specifically for dynamic routes and removes a REPLACE-to-RESET workaround for dynamic route paths. The magic link route is not a dynamic route, so impact is likely minimal.

Verification

• The affected file for magic link handling is src/pages/ValidateLoginPage/index.tsx, which calls signInWithValidateCodeAndNavigate
• The magic link route v/:accountID/:validateCode is configured in src/libs/Navigation/linkingConfig/config.ts at line 17 and has not changed
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 modifies getAdaptedStateFromPath.ts which is responsible for translating deep link paths into React Navigation state — this is the key code path that determines whether the app correctly navigates to ValidateLoginPage when a magic link is opened on iOS

Root Cause

The exact root cause requires device-level testing to confirm. The hypothesis is that the major navigation refactor in PR #85234 introduced a TAB_NAVIGATOR as the primary authenticated navigator, which changed how the navigation root state is built and how iOS-specific route slicing works. This may have introduced a race condition or incorrect state shape when the app is opened via a magic link (universal link) while unauthenticated — causing the navigation system to not reach ValidateLoginPage or to mishandle the initial state, ultimately landing the user on the sign-in ValidateCodeForm without the auto-sign-in having succeeded.