[Due for payment 2026-05-26] [Due for payment 2026-05-26] [$250] Hmm.. it's not here page displayed after entering magic code

[m-natarajan]

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.75-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers): applausetester+mn03employee@applause.expensifail.com, applausetester+0516mn2@applause.expensifail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation (hyperlinked to channel name):

Action Performed:

1. Navigate to staging.new.expensify.com
2. Enter expensifail or gmail account
3. Enter the magic code received

Expected Result:

User able to signin and navigated to Home tab

Actual Result:

Hmm...it's not here page displayed

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.2866.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mkhutornyi

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056536156735942602
• Upwork Job ID: 2056536156735942602
• Last Price Increase: 2026-05-19

[melvin-bot]

Triggered auto assignment to @blimpich (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.

[MelvinBot]

Proposal

Root Cause: PR #87928 ("Replace individual private detail edit pages with unified form + magic code") modified core navigation files — ROUTES.ts, SCREENS.ts, and linkingConfig/config.ts — which altered the route structure. After signing in with a magic code, the app attempts to navigate to the home screen but hits an unmatched route, falling through to the catch-all NOT_FOUND screen (* route) which renders the FullPageNotFoundView ("Hmm... it's not here").

This explains why it reproduces on staging (which includes PR #87928) but not production (which doesn't).

Fix: This has already been reverted by PR #90835, which was merged on May 15 and is included in the 9.3.75-1 deploy checklist. The revert undoes all navigation config changes from PR #87928.

Investigation details

How the not-found page works:

• The catch-all route [SCREENS.NOT_FOUND]: '*' in config.ts matches any URL that doesn't match a defined route
• This renders NotFoundPage → FullPageNotFoundView with the "Hmm... it's not here" message
• After magic code sign-in, if the post-auth redirect targets a path that no longer matches a valid route, the user lands here

PR #87928 changes that likely caused this:

• Modified ROUTES.ts and SCREENS.ts (added/changed route definitions for private personal details)
• Modified linkingConfig/config.ts (navigation linking configuration)
• Modified SETTINGS_TO_RHP.ts (right-hand panel relations)
• These changes could have caused route matching conflicts or broken the default post-sign-in navigation path

Timeline:

• PR Replace individual private detail edit pages with unified form + magic code #87928 merged into staging → introduced the bug
• PR Revert "Replace individual private detail edit pages with unified form + magic code" #90835 (revert) merged May 15, 22:12 UTC → fix available in staging
• Issue [Due for payment 2026-05-26] [Due for payment 2026-05-26] [$250] Hmm.. it's not here page displayed after entering magic code #90880 filed May 16 → tester may have been on a cached build before the revert deployed

Related issues in this deploy:

• Expensify/App#90834 — Profile country field not auto-populating (also caused by PR Replace individual private detail edit pages with unified form + magic code #87928, now closed after revert)

Recommended action: Verify the sign-in flow on the latest staging build (which should include the revert). If the issue persists after confirming the revert is deployed, further investigation into other navigation-related PRs in this deploy will be needed.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: Unable to determine with confidence — see candidates below
Related Issues: #90834 (another deploy blocker in this staging cycle)

Recommendation: NEEDS INVESTIGATION

The "Hmm...it's not here" page appearing immediately after magic code sign-in is a serious regression, but I was unable to identify a single PR with medium or high confidence. The most likely candidates are identified below. The PR authors and reviewers should verify and determine which change introduced this routing failure.

Assigned: @JakubKorytko (PR author of #90044), @ZhenjaHorbach @mountiny (reviewers of #90044), @adhorodyski (PR author of #90696), @Pujan92 @roryabraham (reviewers of #90696)
Labels: DeployBlockerCash label kept — this is a staging-only issue caused by an App PR; DeployBlocker not present so no change needed.

Detailed Analysis

Evidence

Issue summary: After navigating to staging.new.expensify.com, entering an email/phone account, and entering the magic code, users land on the "Hmm...it's not here" page (FullPageNotFoundView) instead of the Home tab. Reproducible on staging only (not production), on Chrome and Safari (web), version 9.3.75-1.

Candidate PR 1 — Medium confidence:
#90044 — "Fix reveal navigation under RHP + re-land reveal workspace route under RHP before dismissing on workspace creation" by @JakubKorytko (merged 2026-05-15T11:58:41Z)

This PR introduced substantial navigation history management via a new addRootHistoryRouterExtension.ts and heavily modified GetStateForActionHandlers.ts. Key concerns:

• Adds REVEAL_PADDING sentinels to state.history that persist across navigation actions.
• The getRehydratedState path (called on every state rebuild, including post-sign-in) now prepends padding sentinels via applyRevealPaddingOffset. If any lingering REVEAL_PADDING exists from a prior navigation epoch and isn't cleared during sign-in's resetRoot, it could misalign the history length vs routes length, causing the browser URL to resolve to an incorrect route — including NOT_FOUND.
• SCREENS.NOT_FOUND is in MODAL_ROUTES_TO_DISMISS (line 38 of GetStateForActionHandlers.ts). If this was newly added in this PR, the handleDismissModalAction path could interact unexpectedly during the post-sign-in navigation transition.
• The PR description notes this fixes prior deploy blockers (Reveal workspace route under RHP before dismissing on workspace creation #89605), which means this code is already known to have subtle side effects.

Candidate PR 2 — Low-Medium confidence:
#90696 — "Make NetInfo reachability ping environment-aware" by @adhorodyski (merged 2026-05-15T15:12:12Z)

This PR changes configureAndSubscribe() in NetworkState.ts from a synchronous call to an async one deferred behind getEnvironment().then(...). On staging builds, if getEnvironment() takes longer to resolve (e.g., on ADHOC or STAGING environments that require a native bridge call), NetInfo may not be configured during the initial sign-in window. If isOffline defaults to false and isLoadingReportData transitions to false before reports arrive, ReportNotFoundGuard could show the "not here" page because shouldShowNotFoundPage = !isLoading && !reportExists becomes true. This is specifically staging-only behavior given the async environment detection path.

Verification

Files affected by the bug path:

• src/pages/inbox/ReportNotFoundGuard.tsx — This is the component that renders FullPageNotFoundView. The shouldShowNotFoundPage condition (line 53) fires when !isLoading && !reportExists. The isLoading guard depends on isLoadingApp !== false, isLoadingReportData, and isLoadingInitialReportActions.
• src/libs/Navigation/AppNavigator/routerExtensions/addRootHistoryRouterExtension.ts — New in PR Fix reveal navigation under RHP + re-land reveal workspace route under RHP before dismissing on workspace creation  #90044; manages history padding.
• src/libs/NetworkState.ts — Modified in PR Make NetInfo reachability ping environment-aware #90696; defers NetInfo configuration.

Verification for PR #90044: Check whether GetStateForActionHandlers.ts existed before this PR and whether SCREENS.NOT_FOUND was already in MODAL_ROUTES_TO_DISMISS. Also verify that after magic code sign-in, Navigation.resetRoot() properly clears any REVEAL_PADDING sentinels from a previous navigation epoch.

Verification for PR #90696: Check if on staging web, getEnvironment() resolution is delayed enough to cause NetInfo to be unconfigured during the sign-in sequence. Specifically verify whether isOffline could be false while isLoadingReportData becomes false before reports are loaded.

Root Cause

The root cause is likely one of the following:

1. The navigation history padding introduced by PR Fix reveal navigation under RHP + re-land reveal workspace route under RHP before dismissing on workspace creation  #90044's addRootHistoryRouterExtension persists across the sign-in state reset, causing the browser URL to be misresolved to NOT_FOUND after authentication completes.

2. The async getEnvironment() deferral in PR Make NetInfo reachability ping environment-aware #90696 causes a window where NetInfo's reachability detection is not configured, leading to incorrect isOffline state that triggers ReportNotFoundGuard to show "not here" before reports have loaded on staging.

Both PRs touch staging-specific code paths and were merged on 2026-05-15 — the same day this regression was introduced.