[Due for payment 2026-05-13] [$250] Travel - Unable to access to travel option, error when accepting Terms and conditions

[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.41-3
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-10911/folder/13177079/41237918/1264591614?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+lov0001@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10
App Component: Workspace Settings

Action Performed:

1. Signin to NewDot with expensifail account
2. Create a workspace
3. Navigate to Workspace Settings > More Features
4. Enable the Travel feature toggle
5. Cick on the Travel menu option > Let's Go
6. Fil the data requested
7. Verify the user is prompted to accept the Terms and Conditions
8. Check the terms box and continue
   Result: Error triggers "Something went wrong. Please try later"

Expected Result:

After accepting terms and conditions user is redirected to https://staging.travel.expensify.com/ a new tab or webview

Actual Result:

After accepting terms and conditions an error triggers "Something went wrong. Please try later"

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034983964972386025
• Upwork Job ID: 2034983964972386025
• Last Price Increase: 2026-03-20

[MelvinBot]

Proposal

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

When a user enables the Travel feature in Workspace Settings, navigates to Travel > Let's Go, fills in the required data, and accepts the Terms and Conditions, they see "Something went wrong. Please try again later." instead of being redirected to travel.expensify.com.

What is the root cause of that problem?

The error message "Something went wrong. Please try again later." is a generic frontend fallback that surfaces whenever the AcceptSpotnanaTerms API command returns a non-200 jsonCode. The frontend code at src/pages/Travel/TravelTerms.tsx:70-125 correctly handles two specific backend error codes (permissionDenied and additionalVerificationRequired), but any other backend failure falls through to the generic error path.

The flow works as follows:

1. User accepts terms → acceptSpotnanaTerms() in src/libs/actions/Travel.ts:13-68 fires a side-effect API call (ACCEPT_SPOTNANA_TERMS)
2. Optimistic data sets TRAVEL_PROVISIONING.isLoading = true and NVP_TRAVEL_SETTINGS.hasAcceptedTerms = true
3. If the backend returns jsonCode !== 200, the Onyx middleware applies failureData which sets TRAVEL_PROVISIONING.errors to the translation key travel.errorMessage ("Something went wrong. Please try again later.")
4. The TravelTerms page displays this error via FormAlertWithSubmitButton

Since the frontend error handling is functioning as designed (it correctly surfaces backend failures), the root cause is on the backend — the AcceptSpotnanaTerms command is returning a non-200 response. This could be due to a Spotnana API provisioning failure, an authentication issue, or a backend exception during the travel account setup process.

There is also a secondary bug in the frontend: the failureData in src/libs/actions/Travel.ts does not revert NVP_TRAVEL_SETTINGS.hasAcceptedTerms back to false after a failure. This means after a failed attempt, the user-level hasAcceptedTerms flag stays true, which could cause BookTravelButton (src/components/BookTravelButton.tsx:145-186) to skip the terms screen on retry and go directly to openTravelDotLink() — which would also fail since provisioning never completed.

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

1. Investigate the backend AcceptSpotnanaTerms command to determine why it's returning non-200 responses. The frontend is correctly surfacing the error — the fix needs to happen server-side. Check backend logs for this command to identify whether it's a Spotnana API issue, timeout, or provisioning failure.

2. Fix the hasAcceptedTerms revert bug in src/libs/actions/Travel.ts: Add NVP_TRAVEL_SETTINGS.hasAcceptedTerms = false to the failureData array so the optimistic update is properly rolled back on failure. This prevents the BookTravelButton from incorrectly skipping the terms page on retry.

3. Call cleanupTravelProvisioningSession() on generic failure in src/pages/Travel/TravelTerms.tsx (it's currently only called on success and permissionDenied). This ensures stale error state in TRAVEL_PROVISIONING doesn't persist and affect subsequent attempts.

What alternative solutions did you explore? (Optional)

• Adding more specific error handling on the frontend for additional backend error codes. However, this only helps if the backend is returning distinguishable error codes — the current evidence suggests the backend is returning a generic non-200 response.
• The jsonCode=200 + no spotnanaToken edge case (line 121 of TravelTerms.tsx) could also be a factor — if the backend returns success but without a token, the promise rejects with "No token received" but no error message is shown to the user (since successData was already applied). This would manifest as the user seeing the terms page with no feedback at all, not the "Something went wrong" error.

---

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 - @shubham1206agra (External)

[melvin-bot]

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

[stitesExpensify]

@MelvinBot look at the logs for applausetester+lov0001@applause.expensifail.com and try to find why acceptSpotnanaTerms actually failed

[MelvinBot]

I wasn't able to query VictoriaLogs directly (MCP tools unavailable in this environment). Here are the exact queries to run in VMUI to find the backend failure:

Query 1 — Find AcceptSpotnanaTerms calls for this user:

Run in VMUI

{type=web} email:="applausetester+lov0001@applause.expensifail.com" AND "AcceptSpotnanaTerms"

Query 2 — Broader spotnana search for this user:

Run in VMUI

{type=web} email:="applausetester+lov0001@applause.expensifail.com" AND "spotnana"

Query 3 — AcceptSpotnanaTerms errors across all users (to see if systemic):

Run in VMUI

{type=web} "AcceptSpotnanaTerms" AND error | sample 50

Query 4 — Auth stream for Spotnana backend errors:

Run in VMUI

{type=auth} "AcceptSpotnanaTerms" OR "Spotnana" | sample 50

What to look for:

• The jsonCode in the response (anything ≠ 200 triggers the generic error)
• Error messages mentioning Spotnana API failures, timeouts, or provisioning errors
• A request_id to trace the full request lifecycle across web + auth streams

Time range: last 30 days (2026-02-18 to 2026-03-20). If you find a request_id, query request_id:=<value> across all streams to get the full picture.

[stitesExpensify]

Looking through the logs I don't believe that this is actually happening on Spotnana's production server, only sandbox. I haven't seen any failures in the logs with shouldUseSandbox=false

[stitesExpensify]

Asked spotnana here https://expensify.slack.com/archives/C066REXJ9D3/p1774020446250829