[$250] Navigation - User does not navigates to ND when Tap on Travel in OD

[applause-bot]

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.4.36-0
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/65074039/folder/13176927/41237638/1576425038
Email or phone of affected tester (no customers): hhhjij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Realme C21Y / Android 11
App Component: Other

Action Performed:

1. Open staging App and log in as a new Gmail account
2. Switch to Expensify Classic
3. Open Menu and Tap on Travel
4. Tap on Book Travel
5. Tap on Got it

Expected Result:

User should Stays on ND after Tapping on Got it as per TC instructions

Actual Result:

After tapping on Got it, User stays on OD

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210884_1784311781974.717.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7210884

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080019554155830826
• Upwork Job ID: 2080019554155830826
• Last Price Increase: 2026-07-22

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/2eb7dd9714058e15b78e6a1d83df2132c1a19e418c9b35120fdd65f50b93ed1d

[MelvinBot]

Issue Analysis

Root Cause: The failure happens entirely inside Expensify Classic (OldDot) — the user never reaches NewDot. The Book Travel → Got it button is an OldDot travel intro/terms screen, and it's OldDot's job to open the handoff into NewDot when it's tapped. In this repro that handoff never fires, so the user stays on OldDot. Because no NewDot code runs until after the handoff lands, this is not an Expensify/App (NewDot) bug — it's a backend/OldDot issue and needs a separate internal investigation.

Recommended Fix: The fix is outside this repo, so I can't propose an App code change. This should be escalated to an internal engineer who can look at the OldDot travel "Got it" redirect for the hybrid Android flow. A likely angle worth checking: the repro uses a brand-new Gmail (public-domain) account with no group workspace, and travel booking is gated on those conditions — the redirect may be getting silently swallowed rather than opening NewDot.

Investigation details

Flow:

1. User in OldDot taps Menu → Travel → Book Travel → Got it (OldDot travel intro/terms screen).
2. OldDot's "Got it" handler is supposed to open NewDot via the public transition handoff and land on the travel route — this step fails; the user stays on OldDot.
3. (If it had succeeded) NewDot would load the travel route → My Trips → Book Travel button → Spotnana redirect.

NewDot (App) side is confirmed healthy — it just never gets invoked:

• Travel landing route TRAVEL_MY_TRIPS (path travel): src/ROUTES.ts
• OldDot→NewDot handoff entry point TRANSITION_BETWEEN_APPS (path transition): src/ROUTES.ts:51
• The travel/Spotnana redirect helpers (openTravelDotLink, buildTravelDotURL) only run after the user is already in NewDot and taps Book Travel, so they can't be the cause of staying on OldDot.

Alternative explanations considered:

• App-side routing/deeplink bug — ruled out: the symptom is that the user never leaves OldDot, which is before any App code path executes.
• Travel gating on public-domain email / missing workspace — plausible and worth confirming; NewDot itself blocks public-domain emails and requires an active policy for booking, and OldDot likely has an analogous gate.

Confidence: High that this is not an App bug. Medium on the exact OldDot mechanism, since the OldDot redirect code isn't in this repo and would need an internal look (and logs from the reproducing Android session to confirm no handoff request fires).

Recent App churn: None meaningful on the travel-deeplink path — only a merge commit touched openTravelDotLink/BookTravelButton. No sign of an App-side regression.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[MelvinBot]

Issue Analysis

Root Cause: The failure happens entirely inside Expensify Classic (OldDot) — the user never reaches NewDot, so no Expensify/App code ever runs. Tapping Book Travel → Got it is an OldDot travel intro/terms screen, and it's OldDot's job to fire the OldDot→NewDot handoff (open NewDot at the transition route with a travel target). In this repro that trigger never fires, so the user stays on OldDot. This is not an App (NewDot) bug — it's an OldDot/backend issue and needs a separate internal investigation.

Recommended Fix: The fix is outside this repo, so I can't propose an App code change. Escalate to an internal engineer with OldDot access to check the "Got it" → NewDot redirect for the hybrid Android flow. Worth checking whether the repro conditions gate the redirect: the account here is a brand-new Gmail (public-domain) address with no workspace and travel not enabled, and if the handoff is conditional on those, it may be silently swallowed rather than opening NewDot.

Investigation details

Flow:

1. User in OldDot taps Menu → Travel → Book Travel → Got it (all OldDot UI).
2. OldDot is supposed to open NewDot via the handoff (native HybridApp switch, or the transition deep link with a travel exitTo target) — this step fails; the user stays on OldDot.
3. (If it had succeeded) NewDot would land on the travel route → My Trips → Book Travel → Spotnana redirect.

NewDot (App) side is confirmed healthy — it just never gets invoked (high confidence):

• The App only owns the receiving end of a transition. It reacts to whatever OldDot sends; it does not initiate the redirect.
• Transition landing route TRANSITION_BETWEEN_APPS (transition) — src/ROUTES.ts:51; travel landing route TRAVEL_MY_TRIPS (travel) — src/ROUTES.ts:3391.
• On HybridApp, HybridAppHandler.tsx only runs after NewDot has been launched by the native/OldDot layer — it does session setup, not the decision to open NewDot. NewDot routes to travel only if OldDot passes a travel exitTo (LogInWithShortLivedAuthTokenPage.tsx).
• The travel/Spotnana redirect helpers (openTravelDotLink, BookTravelButton.tsx) only run after the user is already in NewDot — they are the reverse direction and can't cause the user to stay on OldDot.

Alternative explanations considered:

• App-side routing/deeplink bug — ruled out: the symptom is that the user never leaves OldDot, before any App code path executes.
• Travel gated on public-domain email / missing workspace — plausible and worth confirming; NewDot itself blocks public-domain emails and requires an active policy for booking, and OldDot likely has an analogous gate that could be short-circuiting the redirect.

To confirm with logs (internal): for an affected session, check whether a transition ever started App-side (telemetry spans SPAN_OD_ND_TRANSITION / SPAN_OD_ND_TRANSITION_LOGGED_OUT, started in HybridAppHandler) and whether any transition request or GenerateSpotnanaToken fired around the repro time. If those are entirely absent, it proves NewDot never ran and the regression is 100% OldDot-side.

Related issue: Expensify/App#78875 — "Travel - Opening travel in OD does not opens ND experience, instead 'it's not here' page" (closed, was fixed App-side). That was the receiving-side variant (NewDot opened but landed on the wrong page). This issue is different: NewDot never opens at all, which points upstream to OldDot rather than App routing.

Confidence: High that this is not an App bug. Medium on the exact OldDot mechanism, since the OldDot redirect code isn't in this repo and needs an internal look.

---

Next Steps for Contributor+ team: This needs an internal engineer with OldDot access — there's no App-side change to make here.
Reply with @MelvinBot <your feedback> to refine this analysis.

[ahmdshrif]

Proposal

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

On the hybrid app, Travel in OldDot opens NewDot's Trips screen; tapping "Book Travel" (public-domain login) shows the public-domain error page, and its "Got it" button throws the user back to OldDot instead of keeping them in NewDot.

What is the root cause of that problem?

1. OldDot's Travel menu opens NewDot as a HybridApp single-entry (isSingleNewDotEntry) at the travel route — SCREENS.TRAVEL.MY_TRIPS, which lives inside the RHP travel flow along with every other travel screen:

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

   Lines 1931 to 1952 in 0097920

   	[SCREENS.RIGHT_MODAL.TRAVEL]: {
   	screens: {
   	[SCREENS.TRAVEL.MY_TRIPS]: ROUTES.TRAVEL_MY_TRIPS.route,
   	[SCREENS.TRAVEL.TRAVEL_DOT_LINK_WEB_VIEW]: ROUTES.TRAVEL_DOT_LINK_WEB_VIEW.route,
   	[SCREENS.TRAVEL.DYNAMIC_UPGRADE]: DYNAMIC_ROUTES.TRAVEL_UPGRADE.path,
   	[SCREENS.TRAVEL.DYNAMIC_TCS]: DYNAMIC_ROUTES.TRAVEL_TCS.path,
   	[SCREENS.TRAVEL.TRIP_SUMMARY]: ROUTES.TRAVEL_TRIP_SUMMARY.route,
   	[SCREENS.TRAVEL.TRIP_DETAILS]: {
   	path: ROUTES.TRAVEL_TRIP_DETAILS.route,
   	parse: {
   	reservationIndex: (reservationIndex: string) => parseInt(reservationIndex, 10),
   	},
   	},
   	[SCREENS.TRAVEL.DYNAMIC_DOMAIN_SELECTOR]: DYNAMIC_ROUTES.TRAVEL_DOMAIN_SELECTOR.path,
   	[SCREENS.TRAVEL.DYNAMIC_DOMAIN_PERMISSION_INFO]: DYNAMIC_ROUTES.TRAVEL_DOMAIN_PERMISSION_INFO.path,
   	[SCREENS.TRAVEL.DYNAMIC_PUBLIC_DOMAIN_ERROR]: DYNAMIC_ROUTES.TRAVEL_PUBLIC_DOMAIN_ERROR.path,
   	[SCREENS.TRAVEL.WORKSPACE_CONFIRMATION]: ROUTES.TRAVEL_WORKSPACE_CONFIRMATION.route,
   	[SCREENS.TRAVEL.WORKSPACE_ADDRESS]: ROUTES.TRAVEL_WORKSPACE_ADDRESS.route,
   	[SCREENS.TRAVEL.LEGAL_ENTITY_TAX_ID]: ROUTES.TRAVEL_LEGAL_ENTITY_TAX_ID.route,
   	[SCREENS.TRAVEL.VERIFY_ACCOUNT]: ROUTES.TRAVEL_VERIFY_ACCOUNT.route,
   	},
   	},

   (route 'travel':

   App/src/ROUTES.ts

   Lines 3391 to 3394 in 0097920

   	TRAVEL_MY_TRIPS: {
   	route: 'travel',
   	getRoute: (policyID?: string) => `travel?${policyID ? `policyID=${policyID}` : ''}` as const,
   	},

   ).

2. The tester's login is a public gmail domain, so bookATrip() deterministically routes to the public-domain error page:

   App/src/components/BookTravelButton.tsx

   Lines 140 to 144 in 0097920

   	// Spotnana requires a private domain email for travel booking
   	if (isEmailPublicDomain(primaryContactMethod)) {
   	navigateToPublicDomainError();
   	return;
   	}

   , which pushes the dynamic travel/public-domain-error screen onto the same RHP travel stack (

   App/src/components/BookTravelButton.tsx

   Lines 104 to 107 in 0097920

   	const navigateToPublicDomainError = () => {
   	const dynamicSuffix = hasPolicyIDInActiveRoute() ? DYNAMIC_ROUTES.TRAVEL_PUBLIC_DOMAIN_ERROR.path : DYNAMIC_ROUTES.TRAVEL_PUBLIC_DOMAIN_ERROR.getRoute(activePolicyID);
   	Navigation.navigate(createDynamicRoute(dynamicSuffix));
   	};

   ).

3. That page's "Got it" button calls Navigation.closeRHPFlow():

   App/src/pages/Travel/DynamicPublicDomainErrorPage.tsx

   Lines 50 to 58 in 0097920

   	<FixedFooter>
   	<Button
   	success
   	large
   	style={[styles.w100]}
   	onPress={() => Navigation.closeRHPFlow()}
   	text={translate('common.buttonConfirm')}
   	/>
   	</FixedFooter>

   . Because the travel flow is the only flow in the RHP here, closeRHPFlow pops the entire RHP navigator — including MY_TRIPS, the screen OldDot deep-linked into:

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

   Lines 26 to 32 in 0097920

   	let target = state.key;
   	const hasMoreThanOneRoute = lastRoute?.state?.routes?.length && lastRoute.state.routes.length > 1;
   	if (lastRoute?.state?.key && hasMoreThanOneRoute) {
   	target = lastRoute.state.key;
   	}
   	navigationRef.dispatch({...StackActions.pop(), target});

   .

4. ScreenWrapper arms a usePreventRemove guard on the single-entry screen: when that screen is removed, it calls closeReactNativeApp() and hands control back to OldDot:

   App/src/components/ScreenWrapper/index.tsx

   Lines 216 to 222 in 0097920

   	usePreventRemove(isSingleNewDotEntry && initialURLMatchesActiveRoute && !shouldBlockSingleEntryOldAppExit && !isMfaOverlayScreen, () => {
   	if (!CONFIG.IS_HYBRID_APP) {
   	return;
   	}
   	closeReactNativeApp({shouldSetNVP: false, isTrackingGPS: false});
   	});

   . Per the helper's own docstring, this handoff is only supposed to fire while "the user is still on the screen OldDot deep-linked into":

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

   Lines 12 to 24 in 0097920

   	/**
   	* Whether the initial URL that launched NewDot still matches the currently active route. Used to decide whether the
   	* HybridApp single-entry back handoff should fire (i.e. the user is still on the screen OldDot deep-linked into).
   	*/
   	function doesInitialURLMatchActiveRoute(initialURL: Route | null, activeRouteWithoutParams: string): boolean {
   	const initialURLWithoutParams = initialURL?.replaceAll(/\?.*/g, '');
   	if (!initialURLWithoutParams) {
   	return false;
   	}
   	return normalizeDomainCardDetailRoute(initialURLWithoutParams).endsWith(normalizeDomainCardDetailRoute(activeRouteWithoutParams));
   	}

   . But the arming condition is a render-time snapshot of the imperative, non-reactive Navigation.getActiveRouteWithoutParams() read (

   App/src/components/ScreenWrapper/index.tsx

   Lines 200 to 204 in 0097920

   	useEffect(() => {
   	Navigation.isNavigationReady().then(() => setInitialActiveRouteWithoutParams(Navigation.getActiveRouteWithoutParams()));
   	}, []);
   	const activeRouteWithoutParams = Navigation.getActiveRouteWithoutParams() || initialActiveRouteWithoutParams;
   	const initialURLMatchesActiveRoute = doesInitialURLMatchActiveRoute(initialURL, activeRouteWithoutParams);

   ), taken while MY_TRIPS was focused. Nothing enforces the "still on the entry screen" intent at removal time — on native the guard on the blurred MY_TRIPS stays armed while the error page sits on top (React Compiler caches the imperative read across re-renders).

Structural cause: a descendant screen of a single-entry flow dismisses the whole flow with closeRHPFlow(). The code equates "the RHP flow is closing" with "the user is leaving NewDot", which is wrong when the flow itself is the single-entry surface. So: Got it → whole RHP pops → armed guard on MY_TRIPS prevents the removal and fires closeReactNativeApp() → user lands in OldDot. This explains every detail: hybrid-only (the guard needs isSingleNewDotEntry, so web is unaffected), the exact "Got it" step, and staging + production both reproducing (the dismissal predates the dynamic-route migration of this page in 8def8f5).

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

Dismiss the error page back to the screen it was opened from instead of nuking the whole flow — exactly what the page's own header back button already does (

App/src/pages/Travel/DynamicPublicDomainErrorPage.tsx

Lines 38 to 41 in 0097920

	<HeaderWithBackButton
	title={translate('travel.header')}
	onBackButtonPress={() => Navigation.goBack(backPath)}
	/>

):

// DynamicPublicDomainErrorPage.tsx footer button
onPress={() => Navigation.goBack(backPath)}

backPath (from useDynamicBackPath) resolves to the base route under the dynamic suffix, so the user lands back on the Trips screen and stays in NewDot — the TC-expected result — and the same is true when this page is reached from its other entry screens (WORKSPACE.TRAVEL, SEARCH.ROOT). Apply the identical one-line change to the only sibling with the same "Got it" dismissal, DynamicDomainPermissionInfoPage:

App/src/pages/Travel/DynamicDomainPermissionInfoPage.tsx

Lines 45 to 54 in 0097920

	</View>
	<FixedFooter>
	<Button
	success
	large
	style={[styles.w100]}
	onPress={() => Navigation.closeRHPFlow()}
	text={translate('common.buttonConfirm')}
	/>
	</FixedFooter>

.

Regression safety: the single-entry guard and closeRHPFlow are untouched, so back/dismiss from the Trips screen itself still hands off to OldDot as designed, and every other RHP flow keeps its semantics.

Why the obvious spot-fix fails: patching the guard in ScreenWrapper (disarm when the entry screen is blurred) is unreliable — usePreventRemove is declarative and the arming value is a render-time snapshot of a non-reactive read that the compiler caches on native; that guard also serves every other OldDot deep link (settings, cards, subscription), so loosening it risks their back handoffs. And even a correctly-disarmed guard would still dump the user on the NewDot inbox, not the Travel screen the TC expects.

Secondary (optional): the same closeRHPFlow() pattern exists at two more spots in this flow that kick hybrid users to OldDot the same way — TravelLegalNamePage L32/L37 (it also defeats BookTravelButton's auto-resume effect at L232-L240, which expects the user back on the trips screen) and DynamicTravelTerms L138. These can be aligned in the same PR or a follow-up.

What alternative solutions did you explore? (Optional)

1. Fix the guard staleness in ScreenWrapper (make initialURLMatchesActiveRoute reactive so it disarms on blur) — rejected as headline: it touches every screen and every single-entry handoff, and still lands the user on the inbox instead of Travel.
2. Make closeRHPFlow() hybrid-aware (skip popping the single-entry screen) — rejected: changes a shared primitive used by dozens of flows.
3. "This is Mobile-Expensify/native, not App" — wrong: the exit is triggered entirely by this repo's navigation code; the one-line change above fixes it.

[melvin-bot]

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