[$250] Travel - App crashes after clicking Book travel

[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: 9.3.60-22
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://github.com/Expensify/Expensify/issues/431683
Email or phone of affected tester (no customers): applausetester+sdjnoisjffd44222o@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.2 / Chrome
App Component: Other

Action Performed:

Precondition:

• Log in with Expensifail account.
• Enable Travel in workspace settings.

1. Go to staging.new.expensify.com
2. Open Inbox > FAB > Book travel.
3. Click Book travel.

Expected Result:

App will not crash.

Actual Result:

App crashes after clicking Book travel.

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

logs.txt

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @JS00001

Upwork Automation - Do Not Edit

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The crash occurs in the bookATrip() function in BookTravelButton.tsx when it reaches the code path that calls openTravelDotLink. Inside this function, when the GENERATE_SPOTNANA_TOKEN API call fails or returns no token, the error handling in Link.ts:128-140 uses a double reject(error); throw error; pattern in both the .then() and .catch() handlers. The throw error inside .catch() creates a new rejected promise that propagates through asyncOpenURL, potentially causing an unhandled promise rejection that crashes the error boundary.

A secondary potential root cause is the cross-navigator navigation added in the TRAVEL_INVOICING beta path at BookTravelButton.tsx:111-115, which navigates from the Travel RHP modal to a Workspace RHP route (WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS). This cross-navigator transition could corrupt navigation state.

Note: This analysis is medium confidence — the attached logs.txt does not contain a JS stack trace from the crash itself (only GTM and CORS errors), and Sentry was unavailable for verification. The exact crash line could not be pinpointed without production error data.

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

1. Fix the double-throw pattern in Link.ts: Remove the throw error after reject(error) in both the .then() and .catch() handlers of openTravelDotLink. The reject() already signals the failure to the outer Promise — the additional throw creates a separate rejected promise chain that may not be caught.

2. Verify navigation safety: Ensure the WORKSPACE_TRAVEL_MISSING_PERSONAL_DETAILS navigation from within the Travel RHP doesn't corrupt navigator state. If this beta path is the culprit, consider closing the Travel RHP before navigating to the Workspace RHP.

3. Add error boundary protection: Wrap the openTravelDotLink call at BookTravelButton.tsx:147 in a try/catch or ensure the promise chain has a terminal .catch() handler.

What alternative solutions did you explore? (Optional)

• Checked if policyID being undefined could cause the crash — the button is disabled when !activePolicyID (line 216), so this is safe.
• Checked if usePolicy or getAdminsPrivateEmailDomains could crash with undefined input — both handle undefined gracefully.
• Checked the asyncOpenURL web implementation — it has its own .catch() handler, but this catches a different promise than the one created by throw error inside the inner .catch().

Investigation details

Flow traced:

1. User clicks FAB → TravelMenuItem.openTravel() (TravelMenuItem.tsx:41-47)
2. isTravelEnabled is false (policy not fully provisioned) → navigates to TRAVEL_MY_TRIPS
3. MyTripsPage renders ManageTrips which renders BookTravelButton
4. User clicks "Book travel" → bookATrip() (BookTravelButton.tsx:103)
5. Depending on policy/beta state, reaches openTravelDotLink(policy?.id) at line 147
6. On web, the wrapper calls Link.ts:openTravelDotLink which hits GENERATE_SPOTNANA_TOKEN API
7. If the API fails, the double reject + throw pattern creates an unhandled rejection

Logs analysis: The attached logs.txt contains only preload warnings, GTM errors, CORS failures for BeginSignIn, and aria-hidden warnings — no JS crash stack trace was captured.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[twilight2294]

Proposal

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

The app crashes on native platforms when a user taps "Book travel," instead of gracefully handling the case where the travel token API returns no data.

What is the root cause of that problem?

Unsafe property access on a potentially void response in openTravelDotLink() in index.native. getTravelDotLink() calls API.makeRequestWithSideEffects(), which returns Promise<void | Response<TKey>>. When the API resolves with void (no data), response is undefined, and accessing response.spotnanaToken without optional chaining throws a TypeError:

// index.native.ts line 8
.then((response) => {
    if (response.spotnanaToken) {   // ← TypeError: Cannot read properties of undefined

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

In index.native, add optional chaining on the response access:

.then((response) => {
    if (response?.spotnanaToken) {  // response can be void

This makes the native path consistent with how Link already guards with response?.spotnanaToken in the web variant. When response is void, the condition is falsy and execution falls through to the fallback navigation instead of crashing.

What alternative solutions did you explore? (Optional)

This differs from MelvinBot's proposal, which attributes the crash to a "double reject/throw" pattern in Link.ts and cross-navigator navigation corruption. That analysis targets the wrong file — the native code path goes through openTravelDotLink/index.native.ts, not through Link.ts's openTravelDotLink. The actual crash is a straightforward TypeError from missing optional chaining on a void | Response union type, not an unhandled promise rejection. MelvinBot's proposed fix (removing throw error in Link.ts) would not prevent this crash on native platforms.

[situchan]

@MelvinBot which PR caused this?

[MelvinBot]

This does not appear to be a recent regression — the travel booking code paths (BookTravelButton.tsx, openTravelDotLink/index.native.ts, openTravelDotLink/index.ts, travel portions of Link.ts) have no changes in the current staging cycle (9.3.60-22) or the prior production release.

The unsafe code has been present since these PRs:

• Revert "Revert "open Expensify Travel inside webview on native app"" #65176 (dukenv0307, merged July 2025) — introduced getTravelDotLink() and the native openTravelDotLink with response.spotnanaToken lacking optional chaining
• Set workspace address when attempting to Book Travel #46333 (rushatgabhane, merged August 2024) — introduced the reject(error); throw error; double-throw pattern in Link.ts:openTravelDotLink

This is a latent bug that may have been surfaced by a server-side change to the GENERATE_SPOTNANA_TOKEN endpoint. Sentry crash data and/or checking whether that endpoint's behavior changed recently would help confirm.

[nabi-ebrahimi]

Proposal

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

Clicking Book travel can crash the app instead of failing gracefully when generating the Spotnana token fails.

The call site that reaches the buggy flow is in BookTravelButton.tsx:

App/src/components/BookTravelButton.tsx

Lines 145 to 147 in 9cb33cd

	const isPolicyProvisioned = policy?.travelSettings?.spotnanaCompanyID ?? policy?.travelSettings?.associatedTravelDomainAccountID;
	if (policy?.travelSettings?.hasAcceptedTerms ?? (travelSettings?.hasAcceptedTerms && isPolicyProvisioned)) {
	openTravelDotLink(policy?.id);

What is the root cause of that problem?

The root cause is that openTravelDotLink() in src/libs/actions/Link.ts duplicates the Spotnana token request logic instead of reusing the existing getTravelDotLink() helper, and its duplicated implementation handles the same failure through two separate mechanisms: reject(error) and throw error.

openTravelDotLink() buggy code:

App/src/libs/actions/Link.ts

Lines 113 to 144 in 9cb33cd

	function openTravelDotLink(policyID: OnyxEntry<string>, postLoginPath?: string) {
	if (policyID === null || policyID === undefined) {
	return;
	}
	const parameters: GenerateSpotnanaTokenParams = {
	policyID,
	};
	return new Promise((resolve, reject) => {
	const error = new Error('Failed to generate spotnana token.');
	asyncOpenURL(
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.GENERATE_SPOTNANA_TOKEN, parameters, {})
	.then((response) => {
	if (!response?.spotnanaToken) {
	reject(error);
	throw error;
	}
	const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);
	resolve(undefined);
	return travelURL;
	})
	.catch(() => {
	reject(error);
	throw error;
	}),
	(travelDotURL) => travelDotURL ?? '',
	);
	});
	}

getTravelDotLink() existing shared helper:

App/src/libs/actions/Link.ts

Lines 377 to 392 in 9cb33cd

	function getTravelDotLink(policyID: OnyxEntry<string>) {
	if (policyID === null || policyID === undefined) {
	return Promise.reject(new Error('Policy ID is required'));
	}
	const parameters: GenerateSpotnanaTokenParams = {
	policyID,
	};
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.GENERATE_SPOTNANA_TOKEN, parameters, {}).then((response) => {
	if (!response?.spotnanaToken) {
	throw new Error('Failed to generate spotnana token.');
	}
	return response;
	});

In simple terms, the app already has one helper that fetches the token and throws a single error when the token is missing. But openTravelDotLink() does not use it. Instead, it makes the API request again and wraps it in a custom new Promise(...) with reject(error) and throw error in the same failure path. That creates an unnecessarily fragile flow for the exact action that opens Travel. When token generation fails, the same failure is propagated through multiple layers instead of one clear rejection path, which is why this path can crash instead of being handled cleanly.

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

We should replace the duplicated request/error-handling logic in openTravelDotLink() with a call to getTravelDotLink(), then build the URL from that validated response.

Code to replace in Link.ts:

App/src/libs/actions/Link.ts

Lines 113 to 144 in 9cb33cd

	function openTravelDotLink(policyID: OnyxEntry<string>, postLoginPath?: string) {
	if (policyID === null || policyID === undefined) {
	return;
	}
	const parameters: GenerateSpotnanaTokenParams = {
	policyID,
	};
	return new Promise((resolve, reject) => {
	const error = new Error('Failed to generate spotnana token.');
	asyncOpenURL(
	// eslint-disable-next-line rulesdir/no-api-side-effects-method
	API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.GENERATE_SPOTNANA_TOKEN, parameters, {})
	.then((response) => {
	if (!response?.spotnanaToken) {
	reject(error);
	throw error;
	}
	const travelURL = buildTravelDotURL(response.spotnanaToken, response.isTestAccount ?? false, postLoginPath);
	resolve(undefined);
	return travelURL;
	})
	.catch(() => {
	reject(error);
	throw error;
	}),
	(travelDotURL) => travelDotURL ?? '',
	);
	});
	}

Replace it with this:

function openTravelDotLink(policyID: OnyxEntry<string>, postLoginPath?: string) {
    if (policyID === null || policyID === undefined) {
        return;
    }

    return getTravelDotLink(policyID).then((response) => {
        const travelURL = buildTravelDotURL(response.spotnanaToken ?? '', response.isTestAccount ?? false, postLoginPath);
        asyncOpenURL(Promise.resolve(travelURL), (url) => url ?? '');
    });
}

This change does two things:

1. It removes the duplicated GENERATE_SPOTNANA_TOKEN request logic from openTravelDotLink().
2. It makes openTravelDotLink() rely on the same validation already used by getTravelDotLink(), so token failures go through one consistent rejection path instead of the current custom reject + throw flow.

That is a minimal fix and keeps the behavior aligned with the shared helper that already validates response?.spotnanaToken.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

I explored removing only the throw error lines from the current openTravelDotLink() implementation. That is smaller, but it still keeps two separate implementations for the same token-fetch flow in the same file, which is what made this path fragile in the first place.

I also explored patching the native wrapper path instead. I rejected that because this issue is not best solved by adding another platform-specific guard. The cleaner fix is to stop duplicating the token generation flow and route openTravelDotLink() through the existing shared helper.

[OrygnsCode]

Proposal

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

App crashes after tapping Book travel. Sentry and the attached logs.txt show:

TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at Array.from (<anonymous>)
    at getPathFromState
    at CardContainerInner

The active URL at crash time is /workspaces/:policyID/overview on a freshly created workspace, triggered by the FAB Book travel menu item. The destination URL /travel?policyID=:policyID does land, but the stack card running getPathFromState during the transition throws first.

What is the root cause of that problem?

This is a regression in the in-repo patch at patches/react-navigation/@react-navigation+core+7.16.1+002+fix-crash-when-parsing-emoji.patch (introduced by #65836 for #65709), not a navigation logic bug.

The patch rewrote the param encoder in @react-navigation/core's getPathFromState:

// Upstream
return String(value).replace(/[^A-Za-z0-9\-._~!$&'()*+,;=:@]/g, char => encodeURIComponent(char));

// Patched
return Array.from(value).map(char => /[^A-Za-z0-9\-._~!$&'()*+,;=:@]/g.test(char) ? encodeURIComponent(char) : char).join('');

The patch dropped the String(...) wrapper. That single detail is the whole crash:

value	Upstream (String(value))	Patched (Array.from(value))
'abc'	'abc'	'abc'
'🎉'	❌ URIError: URI malformed (#65709)	✅ '%F0%9F%8E%89'
undefined	✅ ugly string 'undefined', no throw	❌ TypeError: undefined is not iterable (this issue)

That is the exact error string in the logs, and it is the only Array.from site in @react-navigation/core@7.16.1 that sits inside a .map callback. The other Array.from in the package lives in useRouteCache.tsx and is not reachable from CardContainerInner, so the stack trace is unambiguous.

Any state tree that contains a :param placeholder whose resolved value is undefined now crashes where it used to degrade silently. The Book travel crash is one instance. Any cross-navigator transition that hits an incompletely filled route during an animation frame can trip this.

In the repro from the logs, the FAB menu item at TravelMenuItem.tsx:46 calls Navigation.navigate(ROUTES.TRAVEL_MY_TRIPS.getRoute(activePolicy?.id)). During the cross-navigator jump from WorkspaceSplitNavigator into the root Travel RHP, CardContainerInner runs getPathFromState on a state tree where one of the outgoing workspace route params is transiently undefined. Pre-patch: no crash. Post-patch: crash.

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

One line in the existing patch, restoring nullish safety without reverting the emoji fix:

-          return Array.from(value).map(char => /[^A-Za-z0-9\-._~!$&'()*+,;=:@]/g.test(char) ? encodeURIComponent(char) : char).join('');
+          return Array.from(value ?? '').map(char => /[^A-Za-z0-9\-._~!$&'()*+,;=:@]/g.test(char) ? encodeURIComponent(char) : char).join('');

Why value ?? '' and not a revert to String(value)

• String(value) resurrects [Awaiting checklist] [$250] Tax - App crashes on replacing tax code with emoji #65709. For strings containing emoji, '🎉'.replace(regex, encodeURIComponent) ends up calling encodeURIComponent on a surrogate half and throws URIError: URI malformed.
• Array.from(value ?? '') iterates by code point when value is a real string, so the emoji fix is fully preserved, and nullish values become an empty string so the serializer can no longer throw on missing params.

Local verification

Array.from('🎉' ?? '')      // ['🎉']
Array.from(undefined ?? '') // []
Array.from(null ?? '')      // []
Array.from('abc' ?? '')     // ['a', 'b', 'c']

Test plan

• Repro from logs.txt: create a new paid workspace, land on /workspaces/:policyID/overview, open the FAB, tap Book travel. Before the fix: crash. After: navigates to /travel?policyID=:policyID with no crash.
• Emoji regression guard: set a tax code or category to 🎉, exercise any route that serializes it as a :param. URL resolves with percent-encoded emoji, no crash.
• Undefined regression guard: call Navigation.navigate on any route with a :param deliberately omitted, confirm graceful URL instead of crash.
• npm run test for the existing React Navigation path tests.
• Smoke pass on RHP opens across major flows and deep-link cold boots on partially hydrated state.

Risk

Smallest possible scope. No app source changes, no caller changes, no linking config changes. One binary operator inside one existing patch. The behavior change is a strict superset: every input that used to produce a valid URL still produces the same URL byte for byte. The only changed output is for nullish inputs, which previously crashed.

What alternative solutions did you explore?

1. Patch the FAB caller at TravelMenuItem.tsx:46 to close the RHP / Workspace Split before navigating. Rejected. It only masks the crash on this one surface. Other cross-navigator transitions with a transiently undefined :param still crash, because the regression is in the path serializer.
2. Harden ROUTES.TRAVEL_MY_TRIPS.getRoute to never emit a trailing ?. Unrelated. That builder operates before React Navigation receives the URL, but the crash is during state-to-path serialization on the outgoing card, not on the incoming URL. Cosmetic improvement, not a fix.
3. Target BookTravelButton.tsx:113 and the TRAVEL_INVOICING beta flow. Ruled out by the logs. The crash URL is /workspaces/:policyID/overview, meaning Book travel on the Travel page has not been clicked yet. The FAB menu item is what fires it.
4. Revert the emoji patch entirely and accept the [Awaiting checklist] [$250] Tax - App crashes on replacing tax code with emoji #65709 regression. Unacceptable tradeoff: two bugs instead of one.
5. Upgrade @react-navigation/core past 7.16.1 to pick up upstream PR #12679. Out of scope for a bug fix, requires a full navigation bump, already tried and reverted once (commits 0cac09a63d0 / 91e23b7cc02).

The value ?? '' patch is the minimum change that fully resolves this issue, preserves #65709's fix, and guards the whole app against the same regression in every other code path that serializes a state tree.