[$250] [Exploratory] Trip - Trip room incorrectly created under default WS instead of the WS that travel enabled

[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.68-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-26107/folder/13177079/41237919/1395679511
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome, Samsung Galaxy A52 / Android 14, iPhone 13 / iOS 26.5
App Component: Money Requests

Action Performed:

Preconditions

• Logged in using expensifail account (it's recommended to use a new account"
• Create 2 workspaces, one workspace is set as the default (WS 1), and the second workspace is enabled with travel feature (WS 2)

Steps:

1. Navigate to WS 2 setting
2. Click travel -> click "manage expense" -> fill all field using 548 Market for the address (if needed) and proceed until navigated to https://staging.travel.expensify.com
3. Book a flight that set 1 month in the future and proceed until the flight booking is confirmed
4. Navigate to ND
5. Observe the trip room created

Expected Result:

Trip room should be created under the workspace that enabling the travel feature

Actual Result:

Trip room incorrectly created under default WS instead of the WS that travel enabled

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054387159227806960
• Upwork Job ID: 2054387159227806960
• Last Price Increase: 2026-05-27

[MelvinBot]

Proposal

What is the root cause of that problem?

Trip rooms are created entirely on the backend (triggered by a Spotnana webhook after the user completes a booking on travel.expensify.com). The frontend's role is limited to passing a policyID to the GENERATE_SPOTNANA_TOKEN API call, which the backend uses to create a Spotnana auth token.

When the user books travel from the workspace settings page, the correct policyID (WS 2, the travel-enabled workspace) is passed via GetStartedTravel → openTravelDotLink(policyID) → GENERATE_SPOTNANA_TOKEN. So the frontend is sending the right policyID to the backend.

The bug is on the backend side: when the Spotnana webhook fires after booking completion and the backend creates the trip room report, it assigns the trip room to the user's default workspace (WS 1) instead of the workspace whose policyID was used to generate the Spotnana token (WS 2).

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

This appears to be a backend/internal issue. A separate internal investigation is needed.

The backend trip room creation logic (likely in the Spotnana webhook handler) needs to be updated to use the policyID that was associated with the GENERATE_SPOTNANA_TOKEN call, rather than falling back to the user's default/active workspace.

What alternative solutions did you explore? (Optional)

I verified the frontend is not at fault by tracing the full data flow:

Investigation details

Frontend flow (confirmed correct):

1. GetStartedTravel receives policyID from workspace route params and passes it to openTravelDotLink(policyID)
2. openTravelDotLink delegates to Link.openTravelDotLink
3. Link.openTravelDotLink sends {policyID} to GENERATE_SPOTNANA_TOKEN API
4. Backend returns a Spotnana token; frontend opens travel.expensify.com with it
5. User books travel on Spotnana → Spotnana webhook fires → backend creates trip room

No frontend trip room creation exists — the TRIP_ROOM chat type constant is defined but only used for display/rename operations, never for optimistic report creation.

Note on the FAB menu path: The TravelMenuItem component uses NVP_ACTIVE_POLICY_ID (the user's default workspace) rather than looking up the travel-enabled workspace. However, this component's visibility is gated on activePolicy?.isTravelEnabled, so it only appears in the FAB if the default workspace itself has travel enabled — meaning it wouldn't be relevant to this specific reproduction scenario where the default workspace (WS 1) does NOT have travel enabled.

---

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

[melvin-bot]

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

[neerajbachani]

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.