[$250] Login - Clicking " Please sign in again" does nothing in "Session Expired" page

[lanitochka17]

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: undefined
Reproducible in staging?: Yes
Reproducible in production?: https://github.com/Expensify/Expensify/issues/443985
If this was caught during regression testing, add the test name, ID and link from BrowserStack: undefined
Email or phone of affected tester (no customers): undefined
Issue reported by: Applause Internal Team
Bug source: undefined
Device used: undefined
App Component: undefined

Action Performed:

1.Sign in on OD
2.Click support > Concierge
3.Copy the transition link and close the tab
4.Logout on ND
5. Wait for 1 or 2 minute to wait until the auth token expired
6. Paste the transition link on ND
7. Click the "Please sign in again".

Expected Result:

it got redirected to the sign in page

Actual Result:

Clicking " Please sign in again" does nothing in "Session Expired" page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7194377_1782743329137.1781603396838_olease_sign_in.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077834246937457731
• Upwork Job ID: 2077834246937457731
• Last Price Increase: 2026-07-16

Issue Owner

Current Issue Owner: @puneetlath

[MelvinBot]

Proposal

What is the root cause of that problem?

On the "Session Expired" page, the Please sign in again link's onPress calls Navigation.goBack() with no fallback route:

Code references

• src/pages/ErrorPage/SessionExpiredPage.tsx:38-46 — the link handler:

  onPress={() => {
      clearSignInData();
      Navigation.goBack();
  }}

• This page is rendered by LogInWithShortLivedAuthTokenPage.tsx:89, which is the /transition route.
• Navigation.goBack():528-531 — when called with no backToRoute and there is no history to pop, it logs [Navigation] Unable to go back and returns without navigating.

In the repro steps, the transition link is pasted into a fresh tab (original tab was closed, user logged out). So /transition is the first and only entry in the navigation history. When the user clicks "Please sign in again", clearSignInData() runs but Navigation.goBack() has nowhere to go — canGoBack() is false — so it's a no-op and the page doesn't change. That's why clicking the link "does nothing."

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

Pass an explicit fallback route to goBack so it lands on the sign-in page when there is no back history:

onPress={() => {
    clearSignInData();
    Navigation.goBack(ROUTES.HOME);
}}

After clearSignInData() the session is unauthenticated, so navigating to ROUTES.HOME resolves to the public sign-in screen. This mirrors the existing goBackToHome() helper, which already uses goBack(ROUTES.HOME) for exactly this "no history to pop" case.

What alternative solutions did you explore? (Optional)

• Navigation.navigate(ROUTES.HOME) / Navigation.goBackToHome() would also work; goBack(ROUTES.HOME) is preferred because it still pops the /transition route when history does exist (e.g. reaching this page from within the app), avoiding a stale entry.

---

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

[abbasifaizan70]

Proposal

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

When a user opens a "transition link" (e.g. the Concierge deep link copied from OldDot) directly in a browser tab after their auth token has expired, NewDot shows the "Session Expired" page. Clicking the "Please sign in again" link does nothing instead of redirecting the user to the sign-in page.

What is the root cause of that problem?

The "Please sign in again" link lives in SessionExpiredPage. Its onPress clears the sign-in data and then calls Navigation.goBack() with no fallback route:

App/src/pages/ErrorPage/SessionExpiredPage.tsx

Lines 38 to 46 in d769fd5

	<TextLink
	onPress={() => {
	clearSignInData();
	Navigation.goBack();
	}}
	>
	{translate('deeplinkWrapper.signIn')}
	</TextLink>
	</Text>

Navigation.goBack() only performs a fallback navigation (goUp) when a backToRoute argument is supplied. When none is supplied, it just checks whether the native navigation stack canGoBack(), and if not, it logs and silently returns without navigating anywhere:

App/src/libs/Navigation/Navigation.ts

Lines 518 to 541 in d769fd5

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

In the reported repro, the transition link is pasted into the browser after logging out, so /transition (rendered by LogInWithShortLivedAuthTokenPage, which shows SessionExpiredPage once the token has expired) is the only entry in the navigation history — there is no previous screen to go back to. navigationRef.current?.canGoBack() is false, so goBack() hits the early-return branch (Log.hmmm('[Navigation] Unable to go back')) and the click appears to do nothing.

Notably, the same file already special-cases this exact "no back history" situation for the SAML sign-in flow by explicitly navigating home instead of relying on goBack():

App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

Lines 56 to 61 in d769fd5

	if (isSAML) {
	Navigation.isNavigationReady().then(() => {
	// We must replace to remove /transition route from history
	Navigation.navigate(ROUTES.HOME, {forceReplace: true});
	});
	}

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

Instead of unconditionally calling Navigation.goBack() (which no-ops when there is no navigation history to pop), explicitly navigate to ROUTES.HOME once navigation is ready, replacing the current /transition entry so the user lands on the sign-in page regardless of whether there was a prior screen in the stack. This mirrors the existing SAML fallback pattern in LogInWithShortLivedAuthTokenPage.tsx.

https://github.com/Expensify/App/blob/d769fd57fb65190d73383950d7120d6f6189717e/src/pages/ErrorPage/SessionExpiredPage.tsx#L1-L16
import Navigation from '@libs/Navigation/Navigation';

import {clearSignInData} from '@userActions/Session';

import ROUTES from '@src/ROUTES';

import React from 'react';
import {View} from 'react-native';

https://github.com/Expensify/App/blob/d769fd57fb65190d73383950d7120d6f6189717e/src/pages/ErrorPage/SessionExpiredPage.tsx#L38-L42
                        <TextLink
                            onPress={() => {
                                clearSignInData();
                                Navigation.isNavigationReady().then(() => {
                                    Navigation.navigate(ROUTES.HOME, {forceReplace: true});
                                });
                            }}

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 19:18:10 UTC.

Proposal

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

When an OldDot→NewDot transition link is opened with an expired auth token, the "Session Expired" page appears, but clicking "Please sign in again" does nothing — the user is stuck and never reaches the sign-in page.

What is the root cause of that problem?

The link's handler relies on Navigation.goBack() with no fallback route, but in this repro the transition route is the only route in the navigation state, so there is nothing to go back to and goBack() is deliberately a no-op.

The verified chain:

1. Pasting the transition link is a full page load, so React Navigation builds its initial state from the URL path. For standalone public screens, getAdaptedStateFromPath intentionally does not prepend any route underneath — SCREENS.TRANSITION_BETWEEN_APPS is in the PUBLIC_SCREENS set, and when the state contains only public screens it is returned as-is:

   App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

   Lines 46 to 53 in b69fd76

   	const PUBLIC_SCREENS = new Set<string>([
   	SCREENS.VALIDATE_LOGIN,
   	SCREENS.TRANSITION_BETWEEN_APPS,
   	SCREENS.CONNECTION_COMPLETE,
   	SCREENS.BANK_CONNECTION_COMPLETE,
   	SCREENS.UNLINK_LOGIN,
   	SCREENS.SAML_SIGN_IN,
   	]);

   and

   App/src/libs/Navigation/helpers/getAdaptedStateFromPath.ts

   Lines 379 to 386 in b69fd76

   	// Public screens (e.g. ValidateLogin) exist in both PublicScreens and AuthScreens navigators.
   	// Don't prepend TabNavigator because when the user is unauthenticated, PublicScreens is active
   	// and TabNavigator doesn't exist — causing the RESET action to fail.
   	const hasOnlyPublicScreens = currentState.routes.every((route) => PUBLIC_SCREENS.has(route.name));
   	if (hasOnlyPublicScreens) {
   	return currentState;
   	}

   . The stack is therefore exactly one route: the transition page.
2. The expired token makes signInWithShortLivedAuthToken fail, so LogInWithShortLivedAuthTokenPage renders SessionExpiredPage:

   App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

   Lines 81 to 89 in b69fd76

   	if (account?.isLoading) {
   	const reasonAttributes: SkeletonSpanReasonAttributes = {
   	context: 'LogInWithShortLivedAuthTokenPage',
   	isAccountLoading: account.isLoading,
   	};
   	return <FullScreenLoadingIndicator reasonAttributes={reasonAttributes} />;
   	}
   	return <SessionExpiredPage />;

3. The "Please sign in again" link calls clearSignInData() and then bare Navigation.goBack():

   App/src/pages/ErrorPage/SessionExpiredPage.tsx

   Lines 38 to 45 in b69fd76

   	<TextLink
   	onPress={() => {
   	clearSignInData();
   	Navigation.goBack();
   	}}
   	>
   	{translate('deeplinkWrapper.signIn')}
   	</TextLink>

4. goBack() with no backToRoute hits the guard !backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack() — true here because the stack has one route — logs "[Navigation] Unable to go back" and returns without navigating:

   App/src/libs/Navigation/Navigation.ts

   Lines 518 to 531 in b69fd76

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

5. clearSignInData() only clears Onyx keys (ACCOUNT, CREDENTIALS) — it performs no navigation — so the route stays /transition/... and SessionExpiredPage keeps rendering. Every click repeats the silent no-op:

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

   Lines 1053 to 1059 in b69fd76

   	function clearSignInData() {
   	Onyx.multiSet({
   	[ONYXKEYS.ACCOUNT]: null,
   	[ONYXKEYS.CREDENTIALS]: null,
   	});
   	Onyx.merge(ONYXKEYS.HYBRID_APP, {signingInWithSAML: null});
   	}

The structural cause: SessionExpiredPage assumes it was pushed onto an existing stack, but its only mount point is a public deep-link entry route that cold-loads as a single-route stack. This also explains why the report is web (Windows Chrome): pasting a URL into the address bar is the web-only way to cold-load the transition route.

Affected paths checked: SessionExpiredPage has exactly one consumer — LogInWithShortLivedAuthTokenPage, registered once in PublicScreens:

App/src/libs/Navigation/AppNavigator/PublicScreens.tsx

Lines 45 to 48 in b69fd76

	<RootStack.Screen
	name={SCREENS.TRANSITION_BETWEEN_APPS}
	component={LogInWithShortLivedAuthTokenPage}
	/>

. There are no platform-split variants (no index.native.tsx); mWeb/desktop share this same web code path.

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

In SessionExpiredPage, pass the documented fallback route to goBack so the transition route is replaced by the sign-in page when there is no history:

onPress={() => {
    clearSignInData();
    Navigation.goBack(ROUTES.HOME);
}}

This works because with a backToRoute the no-op guard is skipped and goUp runs; ROUTES.HOME maps to TAB_NAVIGATOR (which hosts SignInPage in the unauthenticated navigator:

App/src/libs/Navigation/AppNavigator/PublicScreens.tsx

Lines 33 to 44 in b69fd76

	{/* SignInPage is registered under TAB_NAVIGATOR (the authenticated top-level navigator name) so the public and auth */}
	{/* root structures match. TAB_NAVIGATOR has no path of its own, so the logged-out URL stays at the root "/". */}
	<RootStack.Screen
	name={NAVIGATORS.TAB_NAVIGATOR}
	options={{
	...defaultScreenOptions,
	// If you want to change this, make sure there aren't any animation bugs when signing out.
	// This was put here to prevent excessive animations when resetting the navigation state in `resetNavigationState`
	animation: Animations.NONE,
	}}
	component={SignInPage}
	/>

), and since that route is not in the single-route stack, goUp dispatches a REPLACE — exactly the documented behavior "If backToRoute is not found in the state, replace is also called then" (

App/src/libs/Navigation/Navigation.ts

Lines 422 to 428 in b69fd76

	/**
	* @private
	* Navigate to the given backToRoute taking into account whether it is possible to go back to this screen. Within one nested navigator, we can go back by any number
	* of screens, but if as a result of going back we would have to remove more than one screen from the rootState,
	* replace is performed so as not to lose the visited pages.
	* If backToRoute is not found in the state, replace is also called then.
	*

), implemented at

App/src/libs/Navigation/Navigation.ts

Lines 483 to 491 in b69fd76

	const indexOfBackToRoute = targetState.routes.findLastIndex((route) => doesRouteMatchToMinimalActionPayload(route, minimalAction, compareParams));
	const distanceToPop = targetState.routes.length - indexOfBackToRoute - 1;
	// If we need to pop more than one route from rootState, we replace the current route to not lose visited routes from the navigation state
	if (indexOfBackToRoute === -1 || (isRootNavigatorState(targetState) && distanceToPop > 1)) {
	const replaceAction = {...minimalAction, type: CONST.NAVIGATION.ACTION_TYPE.REPLACE} as NavigationAction;
	navigationRef.current.dispatch(replaceAction);
	return;
	}

. Replacing (not pushing) also keeps /transition out of history. clearSignInData() stays, so the sign-in page opens on the fresh email step.

Precedent: LogOutPreviousUserPage, the other transition-flow page, already uses exactly Navigation.goBack(ROUTES.HOME) to remove itself:

App/src/pages/LogOutPreviousUserPage.tsx

Lines 87 to 92 in b69fd76

	Navigation.isNavigationReady().then(() => {
	// remove this screen and navigate to exit route
	Navigation.goBack(ROUTES.HOME);
	if (exitTo) {
	Navigation.navigate(exitTo as Route);
	}

Regression safety: when a back stack does exist, goUp(ROUTES.HOME) pops back to the existing home/sign-in route instead of replacing, so the warm-history case keeps its current behavior and no shared navigation code changes.

Why the obvious spot-fix fails: "just call Navigation.navigate(ROUTES.HOME)" pushes a new route on top, leaving the dead /transition/... entry in history — browser back returns the user to the stale Session Expired page. And loosening the guard inside Navigation.goBack() itself would change behavior for every bare goBack() call site in the app — the guard is intentional; the call-site fallback parameter exists precisely for this case.

What alternative solutions did you explore? (Optional)

1. Navigation.navigate(ROUTES.HOME, {forceReplace: true}) — functionally close, but goBack(ROUTES.HOME) is the documented fallback pattern and matches the transition-flow precedent, and it correctly pops instead of replacing when history exists.
2. Prepending the sign-in route under public screens in getAdaptedStateFromPath — rejected: the no-prepend is intentional (the comment notes prepending breaks RESET for unauthenticated navigators) and would touch all six public deep-link screens for one page's bug.

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[Abdulloh0109]

Proposal

What is the root cause of that problem?

The transition link is opened in a fresh tab (step 3 closes the original tab, step 6 pastes the link), so /transition is the only entry in the navigation stack. That matters because /transition is a top-level public route — it is registered directly on the PublicScreens root stack, as a sibling of the sign-in screen rather than a child of it:

App/src/libs/Navigation/AppNavigator/PublicScreens.tsx

Lines 35 to 48 in b69fd76

	<RootStack.Screen
	name={NAVIGATORS.TAB_NAVIGATOR}
	options={{
	...defaultScreenOptions,
	// If you want to change this, make sure there aren't any animation bugs when signing out.
	// This was put here to prevent excessive animations when resetting the navigation state in `resetNavigationState`
	animation: Animations.NONE,
	}}
	component={SignInPage}
	/>
	<RootStack.Screen
	name={SCREENS.TRANSITION_BETWEEN_APPS}
	component={LogInWithShortLivedAuthTokenPage}
	/>

and it is a top-level entry in the linking config, so getStateFromPath('/transition?...') produces a root state whose single route is TransitionBetweenApps — nothing is placed underneath it:

App/src/libs/Navigation/linkingConfig/config.ts

Line 23 in b69fd76

[SCREENS.TRANSITION_BETWEEN_APPS]: ROUTES.TRANSITION_BETWEEN_APPS,

With the auth token expired, the sign-in attempt fails and the effect returns early without navigating anywhere, so the page falls through to rendering SessionExpiredPage and the user stays parked on /transition:

App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

Lines 50 to 63 in b69fd76

	if (token && !account?.isLoading) {
	Log.info('LogInWithShortLivedAuthTokenPage - Successfully received shortLivedAuthToken. Signing in...');
	signInWithShortLivedAuthToken(token, isSAML);
	// For SAML sign-ins, navigate to HOME explicitly since the SAML flow
	// doesn't use exitTo deep link routing. For non-SAML flows, let the
	// navigation system handle exitTo routing naturally via setUpPoliciesAndNavigate.
	if (isSAML) {
	Navigation.isNavigationReady().then(() => {
	// We must replace to remove /transition route from history
	Navigation.navigate(ROUTES.HOME, {forceReplace: true});
	});
	}
	return;
	}

App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

Line 89 in b69fd76

return <SessionExpiredPage />;

The "Please sign in again." link then calls Navigation.goBack() with no fallback route:

App/src/pages/ErrorPage/SessionExpiredPage.tsx

Lines 38 to 45 in b69fd76

	<TextLink
	onPress={() => {
	clearSignInData();
	Navigation.goBack();
	}}
	>
	{translate('deeplinkWrapper.signIn')}
	</TextLink>

And goBack() deliberately bails out when there is no backToRoute and nothing to pop:

App/src/libs/Navigation/Navigation.ts

Lines 528 to 531 in b69fd76

	if (!backToRoute && !shouldPopToSidebar && !navigationRef.current?.canGoBack()) {
	Log.hmmm('[Navigation] Unable to go back');
	return;
	}

Because the stack holds only /transition, navigationRef.current?.canGoBack() is false, so goBack() logs [Navigation] Unable to go back and returns. clearSignInData() does run, but it only nulls out ACCOUNT and CREDENTIALS — it cannot move the user, and since the effect's only dependency is [route], the component simply re-renders SessionExpiredPage on the same route. Nothing on screen changes, which is exactly the reported "clicking it does nothing".

This can be confirmed from the console: [Navigation] Unable to go back is logged on every click.

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

In src/pages/ErrorPage/SessionExpiredPage.tsx, replace the history-dependent goBack() with an explicit replace onto the root route:

onPress={() => {
    clearSignInData();
    Navigation.navigate(ROUTES.HOME, {forceReplace: true});
}}

(plus import ROUTES from '@src/ROUTES';)

Why this exact call:

• navigate instead of goBack — goBack()'s no-op on an empty stack is intentional, documented behavior, so the bug belongs to the caller, not to Navigation. SessionExpiredPage is only ever reachable from /transition, which is a cold-start deep-link entry point, so it can never assume a previous screen exists. It must state its destination rather than ask for "back".
• forceReplace: true — the expired /transition URL is a dead end; replacing it keeps it out of history so the browser Back button can't return the user to it.
• ROUTES.HOME — this is the parent page's own established idiom for leaving /transition; the SAML branch does the identical thing, with the comment "We must replace to remove /transition route from history":

  App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

  Lines 56 to 61 in b69fd76

  	if (isSAML) {
  	Navigation.isNavigationReady().then(() => {
  	// We must replace to remove /transition route from history
  	Navigation.navigate(ROUTES.HOME, {forceReplace: true});
  	});
  	}

  
  Since clearSignInData() has just wiped the credentials, the user stays logged out, so NAVIGATORS.TAB_NAVIGATOR resolves to SignInPage in PublicScreens and the logged-out URL settles back at the root / (per the comment on that screen). That matches the Expected Result — "it got redirected to the sign in page".

The fix is correct for the with-history case too: an in-app transition simply gets /transition replaced by the sign-in page instead of popped, which is the same destination.

What alternative solutions did you explore? (Optional)

• Navigation.goBack(ROUTES.HOME) — passing a fallback also clears the early return and routes through goUp(). It works, but it leaves the link's behavior split across two code paths (pop vs. fallback) for no benefit, and it does not guarantee the dead /transition entry is removed from history. navigate(..., {forceReplace: true}) is one deterministic path and matches the parent page.
• Session.resetNavigationState() / Navigation.resetToHome() — both rebuild the authenticated structure (REPORTS_SPLIT_NAVIGATOR / the INBOX split navigator), which does not exist in PublicScreens. Wrong tool for a signed-out screen.
• Fixing Navigation.goBack() to fall back on an empty stack — this would silently change behavior for every caller across the app; far too broad for a one-screen bug.