[$250] Travel - Train Booking - Bad Gateway Error

[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.38-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: #85143
Email or phone of affected tester (no customers): applausetester+aptravel3@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: IPhone 11 /IOS 26.1 / Windows 11
App Component: Other

Action Performed:

1. Open the expensify
2. Create a new Expensifail account.
3. Enable/train travel feature for the account.
4. Attempt to create a new train trip.
5. Tap “Confirm Trip” to finalize the booking.
6. Observe the error message: “Sorry, something went wrong. Invalid response received from server third party supplier (bad gateway).”

Expected Result:

The train booking should complete successfully, and a confirmation of the trip should be displayed.

Actual Result:

Booking fails immediately.
Error message indicates a bad gateway response from a third-party supplier.
Users cannot complete the train trip booking, blocking the core functionality of the app.

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033793015480055055
• Upwork Job ID: 2033793015480055055
• Last Price Increase: 2026-04-14

[MelvinBot]

Proposal

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

When a user attempts to book a train trip through Expensify's travel feature and taps "Confirm Trip", the booking fails immediately with the error: "Sorry, something went wrong. Invalid response received from server third party supplier (bad gateway)." This blocks the core train booking functionality.

What is the root cause of that problem?

This error does not originate from the Expensify App codebase. The entire train booking flow happens within Spotnana's travel platform (travel.expensify.com), which is loaded inside a WebView on native (iOS) or opened as a separate browser tab on web (Chrome).

Here's the evidence chain:

1. The error string does not exist in the App codebase. Searching the entire App/src/ directory for "Invalid response received from server", "third party supplier", or similar patterns returns zero results.

2. The App's role is limited to authentication. The App calls GenerateSpotnanaToken to get a short-lived auth token, then hands off entirely to Spotnana's web app at travel.expensify.com/auth/code?authCode=TOKEN&tmcId=TMC_ID (Link.ts:107-155).

3. No message bridge exists between the WebView and the App. The TravelDotLinkWebview.tsx component renders a plain <WebView> with no onMessage, postMessage, or error interception — the App has zero visibility into what happens inside the Spotnana UI.

4. The App handles its own 502 errors differently. When the Expensify API returns a 502, HttpUtils.ts:98-112 throws EXPENSIFY_SERVICE_INTERRUPTED — a completely different error from what's being reported.

5. Spotnana integrates with third-party rail suppliers (Trainline for UK/Europe, Amtrak for US/Canada). The "third party supplier" referenced in the error is the upstream rail content provider whose API returned a 502/bad gateway to Spotnana's backend.

6. PR Add null checks for rail PNR journey data to prevent crash #85143 is unrelated. That PR only added null checks to isPnrCancelled() in TripReservationUtils.ts for displaying existing trip data — it has nothing to do with the booking creation flow. The bug was discovered during that PR's QA cycle but was not caused by it.

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

No changes to the Expensify App codebase will fix this issue. The error originates from Spotnana's backend (or its upstream rail supplier) and is displayed by Spotnana's own UI.

Recommended next steps:

1. Escalate to Spotnana — Share the error details and ask them to investigate which rail supplier is returning 502 errors and whether this is a transient outage or a systematic issue.
2. Check Spotnana's status/incident page — Determine if there's a known outage affecting rail bookings.
3. Verify if the issue is still reproducing — Since "bad gateway" errors from third-party suppliers are often transient, confirm whether the problem persists or has resolved itself.

What alternative solutions did you explore? (Optional)

• Searched the entire App codebase for the error message — confirmed it does not exist in any App source files, language files, or constants.
• Traced the complete travel booking flow from BookTravelButton.tsx → openTravelDotLink → GenerateSpotnanaToken → TravelDotLinkWebview.tsx to confirm the App's involvement ends at authentication.
• Verified PR Add null checks for rail PNR journey data to prevent crash #85143 only touches post-booking display logic (isPnrCancelled) and cannot affect booking creation.
• Checked the App's HTTP error handling (HttpUtils.ts) to confirm that App-generated 502 errors produce a different message (EXPENSIFY_SERVICE_INTERRUPTED).

---

Next Steps for Contributor+ team: This appears to be a Spotnana/third-party supplier infrastructure issue rather than an App bug. Consider escalating to the Spotnana partnership team. Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When a user attempts to confirm a train booking through the travel feature, the booking fails with a "bad gateway" error originating from a third-party supplier (Spotnana's upstream rail provider). Users are completely blocked from completing the booking with no retry path.

What is the root cause of that problem?

The error comes from Spotnana's third-party rail supplier returning an error response during trip confirmation. Spotnana surfaces this as an "Invalid response received from server third party supplier (bad gateway)" message. On the frontend, the getTravelDotLink function in src/libs/actions/Link.ts calls GenerateSpotnanaToken and then navigates the user into the travel webview. Once inside the webview, the booking confirm step hits Spotnana's API directly, and a transient upstream failure from the rail provider has no retry mechanism -- it simply surfaces the raw error message to the user with no recovery option.

App/src/pages/Travel/TravelDotLinkWebview.tsx

Lines 34 to 42 in 56ff757

	<WebView
	ref={webViewRef}
	source={{uri: url}}
	style={styles.flex1}
	incognito
	originWhitelist={['https://*']}
	/>
	</ScreenWrapper>
	);

The webview renders the Spotnana travel portal directly. When Spotnana's third-party rail supplier returns a bad gateway, the error is shown to the user as a dead end inside the webview with no way to retry or return to a usable state.

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

The fix requires two parts. First, the backend team at Expensify needs to investigate why Spotnana's rail supplier is consistently returning bad gateway errors on trip confirmation -- this may be a misconfiguration in the Spotnana/Amadeus integration or a supplier-side outage that Expensify needs to escalate to Spotnana.

Second, on the frontend the webview in TravelDotLinkWebview.tsx should handle error states by listening to webview navigation state changes or injected JavaScript to detect Spotnana error pages. When an error is detected, a "Try Again" action should be surfaced rather than leaving the user in a dead-end state. The webview should also have an onError and onHttpError handler to catch bad gateway responses that come from the webview itself:

// src/pages/Travel/TravelDotLinkWebview.tsx

+import {useCallback} from 'react';
+import {Alert} from 'react-native';
+import useLocalize from '@hooks/useLocalize';

 function TravelDotLinkWebview({route}: TravelDotLinkWebviewProps) {
     const {translate} = useLocalize();
     const {token, isTestAccount, redirectUrl} = route.params;
     const webViewRef = useRef<WebView>(null);
     const styles = useThemeStyles();

     const url = buildTravelDotURL(token, isTestAccount === 'true', redirectUrl);

+    const handleHttpError = useCallback(
+        ({nativeEvent}: {nativeEvent: {statusCode: number}}) => {
+            if (nativeEvent.statusCode === 502 || nativeEvent.statusCode === 504) {
+                Alert.alert(
+                    translate('travel.errorTitle'),
+                    translate('travel.errorMessage'),
+                    [{text: translate('common.buttonConfirm'), onPress: () => webViewRef.current?.reload()}],
+                );
+            }
+        },
+        [translate],
+    );

     return (
         ...
         <WebView
             ref={webViewRef}
             source={{uri: url}}
             style={styles.flex1}
             incognito
             originWhitelist={['https://*']}
+            onHttpError={handleHttpError}
         />

The translation keys travel.errorTitle and travel.errorMessage already exist in the languages files. The core booking failure itself must be addressed by the backend through Spotnana -- the frontend change ensures users get a retry option instead of a dead end when a transient bad gateway occurs.

What alternative solutions did you explore? (Optional)

N/A

[abelhailefen]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @abelhailefen Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[eVoloshchak]

Attempting to reproduce this one to see if this is a fluke or if it consistently doesn't work

[chengyixu]

Proposal

I'd like to work on this issue.

My read of the problem: The Train Booking feature returns a Bad Gateway (502) error. This is likely an integration issue between the Expensify travel service layer and the upstream train booking API — either the request format has changed, an API endpoint is misconfigured, or an auth token/header is missing in the service-to-service call.

Implementation plan:

• Step 1: Examine the travel booking API integration — find the train booking request handler and inspect headers, payload format, and endpoint URL against current API spec
• Step 2: Compare with working flight/hotel booking calls to identify discrepancies in request construction. Check if there is a missing auth token or if the endpoint URL needs updating
• Step 3: Deploy fix to staging, reproduce the original Bad Gateway scenario with the test account, confirm 200 response and successful booking flow

Relevant skills: TypeScript, React Native, REST API integrations, Expensify codebase patterns, 8 years full-stack.
Commitment: Available now, deliver in 2-3 days.