[Due for payment 2026-07-29] [$250] [Exploratory] Web - Login - Nothing happen after click on request one here link on MC expired page

[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.75-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-29927/folder/13176924/41237554/1417945561
Email or phone of affected tester (no customers): leungbratt6+1305@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: User Settings

Action Performed:

1. Open the New Dot app
2. Enter an email in the box
3. Click Continue -> Click on Go Back to make another request
4. Click Continue again to make another request
5. Navigate to the email inbox and copy the magic link change it to staging of the 1st email
6. Paste on the new tab
7. Click on the request one here link on the Magic code expired page

Expected Result:

A login page with the Magic code to enter is open

Actual Result:

Nothing happen

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078168533462530811
• Upwork Job ID: 2078168533462530811
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @mallenexpensify

[sandipanghos]

@jponikarchuk can i start working on this issue. will it be added as paid/external/help wanted list.

[MelvinBot]

Proposal

What is the root cause of that problem?

When a magic-link URL (/v/<accountID>/<validateCode>) is opened directly in a fresh tab, that /v/... route becomes the root of the navigation stack — there is nothing behind it.

On the "Magic code expired" page, the "request one here" link fires two actions (ExpiredValidateCodeModal.tsx:46-48):

beginSignIn(credentials?.login ?? '');
Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack);

beginSignIn() requests a new code in the background, but the UI transition depends entirely on Navigation.goBack(). From the root /v/... route there is no previous screen, so goBack() hits its no-op guard, logs [Navigation] Unable to go back, and returns without navigating (Navigation.ts:518-552). The expired-code modal stays mounted → "nothing happens."

This is why the bug only reproduces in a new tab: when the user was already on the sign-in page in the same session, TAB_NAVIGATOR (which hosts SignInPage) sits below /v/ in the stack, so goBack() succeeds and reveals the code-entry form.

Evidence / data flow

• SignInPage (the magic-code entry form) and ValidateLoginPage (/v/...) are sibling screens in the PublicScreens RootStack (PublicScreens.tsx:32-53). Landing directly on /v/... never pushes TAB_NAVIGATOR, so there is nothing to go back to.
• The 2FA path in the same file already documents and works around this exact behavior — it explicitly notes "navigate/goBack no-op from the public /v/ route" and instead resets the stack to TAB_NAVIGATOR (ValidateLoginPage/index.web.tsx:119-130).

Bug manifestation:

1. Open /v/<accountID>/<validateCode> in a fresh tab → RootStack has only VALIDATE_LOGIN at index 0.
2. Code expired → autoAuthState === FAILED, not 2FA → ExpiredValidateCodeModal renders.
3. Click "request one here" → beginSignIn() runs, goBack is queued.
4. goBack(): no backToRoute, canGoBack() is false → logs and returns. No navigation.
5. Modal stays mounted → user sees nothing change.

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

In the "request one here" onPress, after calling beginSignIn(login), surface the sign-in page the same way the 2FA path does instead of relying on goBack(). Reset the public stack to the navigator that hosts SignInPage so the magic-code entry form is shown:

• Replace the Navigation.goBack call with navigationRef.reset({index: 0, routes: [{name: NAVIGATORS.TAB_NAVIGATOR}]}) (guarded by Navigation.isNavigationReady()), mirroring ValidateLoginPage/index.web.tsx:119-130.

This makes the link work whether /v/... is the stack root (fresh tab) or has history (same session), landing the user on the sign-in page with the newly requested code.

What alternative solutions did you explore? (Optional)

Pass an explicit fallback route to goBack (e.g. Navigation.goBack(ROUTES.HOME)), but that doesn't target the sign-in page and wouldn't render the code-entry form; the reset to TAB_NAVIGATOR is the pattern already proven for the 2FA case.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/90929) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[wildan-m]

Proposal

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

On web Chrome, opening a stale magic-code link in a new browser tab shows the "Magic code expired" page, but clicking the "request one here" link does nothing visible — the user stays on the same expired page and cannot enter a fresh magic code. Expected: a sign-in page with a magic-code input is shown so the user can complete sign-in with the newly requested code.

What is the root cause of that problem?

The "request one here" link in ExpiredValidateCodeModal runs two actions: a beginSignIn API call to request a new code, and a navigation step that tries to leave the expired-code page.

App/src/components/ValidateCode/ExpiredValidateCodeModal.tsx

Lines 39 to 46 in d8068e7

	<TextLink
	onPress={() => {
	beginSignIn(credentials?.login ?? '');
	Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack);
	}}
	>
	{translate('validateCodeModal.requestOneHere')}
	</TextLink>

The navigation step calls Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack) — that is, Navigation.goBack() with no fallback route.

In the bug's repro, the user pastes the magic-code URL into a brand-new tab, so this tab's React Navigation stack has only one entry (the /v/<accountID>/<validateCode> deep link). When Navigation.goBack() runs with no fallback, the implementation reaches the no-history branch:

App/src/libs/Navigation/Navigation.ts

Lines 509 to 536 in d8068e7

	function goBack(backToRoute?: Route, options?: GoBackOptions) {
	clearSelectedText();
	if (!canNavigate('goBack', {backToRoute})) {
	return;
	}
	const runImmediately = !options?.waitForTransition;
	TransitionTracker.runAfterTransitions({
	callback: () => {
	if (backToRoute) {
	goUp(backToRoute, options);
	} else if (shouldPopToSidebar) {
	popToSidebar();
	} else if (!navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;
	} else {
	navigationRef.current?.goBack();
	}
	if (options?.afterTransition) {
	TransitionTracker.runAfterTransitions({callback: options.afterTransition, waitForUpcomingTransition: true});
	}
	},
	runImmediately,
	});
	}

There, navigationRef.current?.canGoBack() returns false because the tab has no prior screen, so goBack just logs [Navigation] Unable to go back and returns. The user remains on /v/..., and because ValidateLoginPage keeps rendering ExpiredValidateCodeModal whenever autoAuthState === FAILED, the page does not change — even though beginSignIn did fire and a new code was actually emailed.

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

Lines 82 to 95 in d8068e7

	return (
	<>
	{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}
	/>
	)}

So the visible behavior is "nothing happens", but the underlying cause is that the navigation step has no fallback for a tab that was opened directly via deep link.

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

In ExpiredValidateCodeModal.tsx, pass a fallback route to Navigation.goBack so the link works regardless of whether the tab has prior history.

Specifically, change the link's onPress so that, after calling beginSignIn(credentials.login), the deferred navigation call is Navigation.goBack(ROUTES.HOME) instead of Navigation.goBack. The new argument is the backToRoute parameter — when provided, Navigation routes through goUp(backToRoute) instead of through the canGoBack() branch, so it always navigates somewhere meaningful:

• Same-tab case (user clicked the magic link from inside the app and there is history): the behavior is the same as today — the user lands back at the sign-in entry point. ROUTES.HOME resolves to the same destination they would have popped to.
• New-tab / fresh-context case (the bug's repro): instead of becoming a no-op, navigation REPLACEs the current /v/... deep-link route with the home/sign-in route. That route's sign-in flow already knows how to render the magic-code input for the email currently stored in credentials.login, and because beginSignIn just fired, the freshly issued code from the user's inbox is the valid one.

This is a small change confined to ExpiredValidateCodeModal.tsx — the deferred call becomes () => Navigation.goBack(ROUTES.HOME) in the existing onPress callback, plus a one-line ROUTES import at the top of the file. No other files need to change. The deferred setNavigationActionToMicrotaskQueue wrapper is kept so the new code request's Onyx update still flushes before navigation runs.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90929-magic-code-expired-request-one-here?expand=1

What alternative solutions did you explore? (Optional)

Resetting autoAuthState to NOT_STARTED on click was considered, since that would cause ValidateLoginPage to swap ExpiredValidateCodeModal for ValidateCodeModal in place. It was rejected because the URL would still be /v/<expired-code> — confusing if the page is reloaded, and bookmarkable to a known-broken state. Navigating to ROUTES.HOME both updates the URL and re-enters the normal sign-in surface, which is what the bug report expects to see.