[$250] Login - Blank page opens when login via magic link different session

[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: v9.3.66-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-24946/folder/13176924/41237548/1387585647?sort=%2Bstatus_id&p=2
Email or phone of affected tester (no customers): gocemate+b215490600@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Other

Action Performed:

1. Log in with existing account and request magic code
2. Navigate to email and locate the magic link - change to staging if needed
3. Open an new INCOGNITO window and navigate to the staging link
4. Verify the "Here's your magic code" page is displayed
5. Verify there's a link to "Just sign In here"

Expected Result:

User should log in

Actual Result:

Blank page opens

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: @mkhutornyi

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051363824384416616
• Upwork Job ID: 2051363824384416616
• Last Price Increase: 2026-05-04

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user opens a magic link in an incognito/different-session browser window and clicks "Just sign in here", credentials.login is never populated because the signInWithValidateCode success handler only sets credentials.accountID and credentials.validateCode — not credentials.login.

After the API call succeeds, the component re-renders with isSignedIn=true, autoAuthState=JUST_SIGNED_IN, but login=undefined. At this point, every render condition in ValidateLoginPage/index.website.tsx evaluates to false:

• Line 84: requires FAILED state — false
• Line 85: requires !isSignedIn && !!login — false
• Line 88: requires !!login — false (this is the key gap)
• Line 90: requires NOT_STARTED — false
• Line 96: requires SIGNING_IN — false

The component renders an empty <></> fragment — a blank page. Eventually AppNavigator switches to AuthScreens (which is lazy-loaded with Suspense fallback={null}), extending the blank period until the JS chunk loads and ValidateLoginPage remounts and calls Navigation.goBack().

What changes do you think we should make in order to solve the problem?

Remove the !!login guard from the JustSignedInModal render condition on line 88 of ValidateLoginPage/index.website.tsx:

Before: autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo && !!login
After: autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo

This ensures JustSignedInModal renders during the transition period regardless of whether credentials.login is populated, eliminating the blank page. The user sees the "You have been signed in" modal until AuthScreens loads and navigation completes.

What alternative solutions did you explore? (Optional)

An alternative would be to populate credentials.login in the signInWithValidateCode success handler (from the API response), but this would require server-side changes and doesn't address the fundamental render gap where no condition matches the incognito sign-in state.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When expenses are grouped by Merchant on the Spend → Expenses search page, clicking the group checkbox triggers a selection handler in SearchListWithHeader that iterates over child transaction items to build the set of IDs to select. In the grouped view, each group header list item is expected to carry a transactions (or equivalent child items) array. However, the grouped list item shape built in SearchUIUtils doesn't always include that field — so when the checkbox handler tries to call .map() on it, it gets undefined, throws a TypeError, and React Native's error boundary crashes the page.

The selection handler lives here:
👉 https://github.com/Expensify/App/blob/main/src/components/Search/SearchListWithHeader.tsx

The grouped item builder that produces the incomplete item shape lives here:
👉 https://github.com/Expensify/App/blob/main/src/utils/SearchUIUtils.ts

The crash only surfaces in the grouped view because flat (ungrouped) list items go through a different code path that always has transaction IDs attached directly to the item. Group headers, however, are constructed separately and don't always carry the child transactions array, leaving the checkbox handler with nothing safe to iterate over.

What changes do you think we should make in order to solve the problem?

There are two changes needed — a defensive guard at the point of use, and a data-contract fix at the source.

First, in the group checkbox press handler inside SearchListWithHeader, guard against a missing child array so a missing transactions field produces an empty selection rather than a crash:

- const childTransactionIDs = item.transactions.map((t) => t.keyForList);
+ const childTransactionIDs = (item.transactions ?? []).map((t) => t.keyForList);

Second, in the grouped list item builder in SearchUIUtils, ensure every group header item is constructed with a transactions field so the contract is explicit and safe for all callers going forward:

- return {keyForList: groupKey, text: groupName, isGroupHeader: true};
+ return {keyForList: groupKey, text: groupName, isGroupHeader: true, transactions: []};

transactions is already used elsewhere in the search list item type — this just makes it a required field on group headers rather than implicitly absent. Together, the two changes eliminate the crash: the first is a safety net at the usage site, the second makes the data shape consistent at the construction site.

What alternative solutions did you explore?

I considered wrapping the group checkbox handler in a try/catch to silently swallow the error, but that would hide the bad data rather than fix it — the group would still silently fail to select anything. I also looked at whether the grouped view could reuse the same flat item shape entirely, but that would require a larger refactor of SearchUIUtils well beyond the scope of a targeted bug fix. The two-line guard above is the minimal, safe change that fixes the crash without touching unrelated code paths.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @DylanDylann (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022051363824384416616

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user opens a magic link in a fresh incognito session (no stored credentials) and clicks "Just sign in here" to authenticate, the app shows a blank page instead of the expected login success modal. The user successfully authenticates—the server confirms the sign-in and sets isSignedIn=true—but the UI fails to render any confirmation or next step, leaving the user stranded on a blank screen.

What is the root cause of that problem?

The bug originates in src/pages/ValidateLoginPage/index.website.tsx at line 88, in the JSX render condition for the non-2FA JustSignedInModal:

App/src/pages/ValidateLoginPage/index.website.tsx

Line 88 in cab81ee

{autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo && !!login && <JustSignedInModal is2FARequired={false} />}

The condition requires !!login to be true:

{autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo && !!login && <JustSignedInModal is2FARequired={false} />}

In a fresh incognito session, credentials.login is never populated from storage because no prior session exists. When signInWithValidateCode() succeeds via the "Just sign in here" flow, autoAuthState transitions to JUST_SIGNED_IN and isSignedIn becomes true—but login remains undefined. The !!login guard evaluates to false, blocking the modal render. Simultaneously, all four other JSX branches fail their conditions: ExpiredValidateCodeModal needs FAILED state, the 2FA JustSignedInModal (line 85–87) needs is2FARequired=true, ValidateCodeModal needs autoAuthState===NOT_STARTED, and FullScreenLoadingIndicator needs SIGNING_IN state. With all conditions false, the component returns an empty fragment—a blank page.

The guard was intended to distinguish "user just signed in via magic link in this session" from "user was already signed in and is just navigating," but it inadvertently excludes fresh incognito sessions where no login was ever stored. Compare the working analog at src/pages/ValidateLoginPage/index.tsx (the non-website variant):

App/src/pages/ValidateLoginPage/index.tsx

Line 1 in cab81ee

import React, {useEffect} from 'react';

That version does not apply the !!login guard, correctly rendering the success modal.

What changes do you think we should make in order to solve the problem?

1. File: src/pages/ValidateLoginPage/index.website.tsx
   Function: ValidateLoginPage
   Edit: Remove the !!login guard from line 88. The condition autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo is already sufficient to uniquely identify the post-sign-in success state. The JUST_SIGNED_IN state only becomes active after a sign-in event within the current session, so the distinction between "just signed in" and "already signed in" is already encoded. The !!login check incorrectly blocks the modal when login is undefined—a valid scenario in fresh incognito sessions—so it must be removed.

   New condition:

   {autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo && <JustSignedInModal is2FARequired={false} />}

   Blast radius: Isolated to the JSX render condition on line 88. No helper functions, shared state, or other components are modified. The change is a strict simplification of a local conditional.

What alternative solutions did you explore? (Optional)

1. Replace the condition with isUserClickedSignIn && JUST_SIGNED_IN (candidate from S2 analysis)
   Rejection reason: isUserClickedSignIn is defined as !login && isSignedIn && (...), which evaluates to false whenever login is stored. This would regress the expired-session re-auth scenario: a user with stored credentials opens a magic link, signs in via magic link, and should see the success modal, but isUserClickedSignIn would remain false because !login is false. The modal would not render.

2. Add Navigation.goBack() in a useEffect for the JUST_SIGNED_IN + !login path
   Rejection reason: This would send the user backward through navigation after a successful sign-in, defeating the purpose of the sign-in flow. The expected outcome per the issue is successful login confirmation, not navigation back.

[mukhrr]

Proposal

What is the root cause of that problem?

When the magic link is opened in a fresh browser session (incognito), credentials.login is never populated — that field is only set when the user types their email into the SignIn form, which doesn't happen on a magic-link-only flow. After "Just sign in here" succeeds, the API returns 200 and Onyx merges authToken, accountID, email, encryptedAuthToken onto session, but the successData only writes accountID and validateCode to CREDENTIALS — not login:

App/src/libs/actions/Session/index.ts

Lines 922 to 930 in 053ec53

	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CREDENTIALS,
	value: {
	accountID,
	validateCode,
	},
	},

So at the moment autoAuthState becomes JUST_SIGNED_IN, the state is isSignedIn=true, login=undefined, exitTo=undefined. None of the render branches in ValidateLoginPage/index.website.tsx match, since both JustSignedInModal branches require !!login:

App/src/pages/ValidateLoginPage/index.website.tsx

Lines 84 to 106 in 053ec53

	{autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.FAILED && !is2FARequired && <ExpiredValidateCodeModal />}
	{(autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN || autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.FAILED) && is2FARequired && !isSignedIn && !!login && (
	<JustSignedInModal is2FARequired />
	)}
	{autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.JUST_SIGNED_IN && isSignedIn && !exitTo && !!login && <JustSignedInModal is2FARequired={false} />}
	{/* If session.autoAuthState isn't available yet, we use shouldStartSignInWithValidateCode to conditionally render the component instead of local autoAuthState which contains a default value of NOT_STARTED */}
	{(!effectiveAutoAuthState ? !shouldStartSignInWithValidateCode : autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.NOT_STARTED && !isNavigatingToExitTo) && (
	<ValidateCodeModal
	accountID={Number(accountID)}
	code={validateCode}
	/>
	)}
	{(!effectiveAutoAuthState ? shouldStartSignInWithValidateCode : autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.SIGNING_IN) && (
	<FullScreenLoadingIndicator
	reasonAttributes={{
	context: 'ValidateLoginPage',
	isSigningIn: autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.SIGNING_IN,
	shouldStartSignInWithValidateCode,
	hasAutoAuthState: !!autoAuthState,
	}}
	/>
	)}
	</>

The fallback Navigation.goBack() in the existing effect doesn't help because incognito has no history (the console confirms [hmmm] [Navigation] Unable to go back). The screen renders nothing → blank page. The same blank page also shows when the user revisits a /v/... URL inside an incognito session that has Onyx-restored credentials from an earlier sign-in (Onyx persists to IndexedDB, which is shared across same-origin tabs in the same incognito profile).

What changes do you think we should make in order to solve the problem?

I'd extend the existing post-mount effect in ValidateLoginPage/index.website.tsx so that, when the user is signed in but has no login (i.e. no original tab to head back to), we route them to the app home instead of leaving a blank page. The existing 2FA same-tab goBack() branch is preserved for the signed-out case it already handled. The render gates that depend on !!login stay as-is, so the multi-tab "Abracadabra, head back to your original tab" UX is unchanged when a login is present.

 useEffect(() => {
-    if (!!login || !cachedAccountID || !is2FARequired) {
-        if (exitTo) {
-            handleExitToNavigation(exitTo);
-        }
+    if (exitTo) {
+        handleExitToNavigation(exitTo);
+        return;
+    }
+    if (login) {
         return;
     }
-
-    // The user clicked the option to sign in the current tab
     Navigation.isNavigationReady().then(() => {
-        Navigation.goBack();
+        // No `login` means there's no original tab to head back to (e.g. magic link opened
+        // in incognito). Once signed in, route to the app home instead of leaving a blank
+        // page; otherwise the existing same-tab 2FA flow falls back to goBack().
+        if (isSignedIn) {
+            Navigation.navigate(ROUTES.HOME);
+            return;
+        }
+        if (cachedAccountID && is2FARequired) {
+            Navigation.goBack();
+        }
     });
-}, [login, cachedAccountID, is2FARequired, exitTo]);
+}, [login, cachedAccountID, is2FARequired, exitTo, isSignedIn]);

This covers both observed shapes of the bug:

• Fresh incognito → user sees ValidateCodeModal, clicks "Just sign in here", sign-in completes (isSignedIn=true, login=undefined) → effect re-runs on the dep change and lands them on Home.
• Same incognito profile with Onyx-restored credentials → isSignedIn is already true at mount, the same effect lands them on Home rather than rendering blank.

A small import addition is also needed: import ROUTES from '@src/ROUTES';.

What alternative solutions did you explore? (Optional)

1. Drop !!login from the JustSignedInModal render gates. This unblocks the blank page but shows "Abracadabra, head back to your original tab" — misleading because in incognito there is no original tab. Verified manually: the user is "signed in" but stuck on a dead-end screen, which doesn't satisfy the bug's Expected Result of "User should log in".
2. Use Navigation.resetToHome() instead of Navigation.navigate(ROUTES.HOME). Verified manually too: resetToHome dispatches into ReportsSplitNavigator, which doesn't yet exist in the navigator state during the PublicScreens → AuthScreens transition, so it logs [handleReplaceReportsSplitNavigatorAction] ReportsSplitNavigator has not been found in the navigation state. and the page stays blank. Navigation.navigate(ROUTES.HOME) is path-based and works regardless of the navigator transition timing.
3. Populate credentials.login in signInWithValidateCode's successData. This would make the existing !!login render guards work, but the email isn't available client-side at the time the optimistic/success Onyx data is built — we'd have to thread it through the response, which is more invasive than gating navigation on isSignedIn alone.

Result:

REC-20260508101731.mp4

[oqildev]

Proposal

What is the root cause of that problem?

On web, when a magic link https://staging.new.expensify.com/v/{accountID}/{validateCode} is opened in an incognito window, the route resolves to ValidateLoginPage (website variant). In a fresh incognito session none of session?.authToken, credentials?.login, or the route param exitTo exist, so on src/pages/ValidateLoginPage/index.website.tsx:39 the boolean shouldStartSignInWithValidateCode evaluates to false because of the (!!login || !!exitTo) clause that was tightened in e809d0bdd3b (it requires either a stored login or an exitTo to auto‑initiate sign‑in).

That should mean the render guard on src/pages/ValidateLoginPage/index.website.tsx:90 renders ValidateCodeModal. However, the recent refactor in 8e2368d396c ("Revert 'Revert [Onyx Audit] Migrate keys to RAM-only part 2/2'") replaced the old useOnyx(ONYXKEYS.SESSION, {initWithStoredValues: isSignedIn, ...}) guard with a useState(isSignedIn) + setHasInitialized(true) masking pattern at src/pages/ValidateLoginPage/index.website.tsx:32-34. The new pattern produces three sequential renders for an unauthenticated user:

1. Mount: hasInitialized=false, so effectiveAutoAuthState=undefined. Guard takes the !effectiveAutoAuthState branch → renders ValidateCodeModal.
2. After useEffect fires setHasInitialized(true): hasInitialized=true but autoAuthState is still undefined (Onyx merge from initAutoAuthState is async). Guard re-evaluates the same branch → re-renders ValidateCodeModal.
3. After Onyx commits autoAuthState=NOT_STARTED: guard flips to the autoAuthStateWithDefault === NOT_STARTED && !isNavigatingToExitTo branch — same boolean result, but it's a different expression so React unmounts and remounts ValidateCodeModal.

The unmount/remount discards the useMemoizedLazyIllustrations(['MagicCode']) async chunk load started in step 1 (isMounted flag in src/hooks/useLazyAsset.ts:127-140 prevents setAssets from running on the unmounted instance), and the new mount in step 3 starts another async load. Until that resolves the modal renders with assets={}, so the <Icon src={illustrations.MagicCode} /> and the entire <View style={styles.deeplinkWrapperContainer}> paint with no measurable content because Icon returns nothing for an undefined source — leaving only the full‑screen theme.appBG background and producing the blank page the tester sees. The "Just sign In here" text link inside the same <View> does not paint until the chunk eventually loads, and on a slow first connection in incognito (cold cache) the chunk request can stall behind other prefetches, leaving the page visibly blank.

What changes do you think we should make in order to solve the problem?

Eliminate the unmount/remount of ValidateCodeModal by keeping the render guard on a single boolean expression across all three renders. In src/pages/ValidateLoginPage/index.website.tsx:32-34 drop the useState/hasInitialized/effectiveAutoAuthState indirection and compute a single derived value, e.g. set effectiveAutoAuthState = isSignedIn ? autoAuthState : autoAuthState ?? CONST.AUTO_AUTH_STATE.NOT_STARTED (or simply normalize to NOT_STARTED for unauthenticated users). Then change line 90 to a stable predicate: render ValidateCodeModal whenever autoAuthStateWithDefault === NOT_STARTED && !isNavigatingToExitTo. With a stable predicate the modal is mounted exactly once across the three renders, and the lazy illustration chunk that was kicked off on first mount can complete and call setAssets on the still‑mounted instance.

Also remove the now‑unused setHasInitialized(true) line at src/pages/ValidateLoginPage/index.website.tsx:44 and the corresponding useState import. The "stale FAILED autoAuthState" concern that motivated the original refactor is already handled because initAutoAuthState is invoked synchronously on mount and overwrites stale values to NOT_STARTED/JUST_SIGNED_IN before the user can interact.

A defensive secondary fix in src/components/ValidateCode/ValidateCodeModal.tsx:54-58: when illustrations.MagicCode is undefined the wrapping <View> should still render the headline, code digits, and "Just sign In here" link. Currently the children render but the modal's only visible "anchor" (the icon) is missing during the chunk load, which is what makes the unmount/remount visually catastrophic. Pass a PlaceholderIcon fallback so the layout is never empty.

What alternative solutions did you explore? (Optional)

There are no other proposals on this issue yet. An alternative would be to keep the useState/hasInitialized masking but stabilize the boolean — that works but leaves the misleading three‑phase render. Another alternative would be to revert just the guard expression on lines 90 and 96 back to the pre‑8e2368d396c shape (!autoAuthState ? ... : ...) without restoring the initWithStoredValues: isSignedIn Onyx option; this also avoids the remount but keeps autoAuthState=undefined as a possible "valid" runtime state, which the rest of the file does not really expect. The cleaner change is to normalize autoAuthState to NOT_STARTED for unauthenticated users and use a single predicate, as described above. The earlier "Skip prepending TabNavigator for public screens" fix in 15020f6ab2b is unrelated — it only affects the navigator RESET action, not what ValidateLoginPage paints.

[github-actions]

⚠️ @oqildev Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).