Repository navigation
Travel - Trip "Total" changes to 0 (zero) after opening and closing trip #105339
Description
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: v9.5.25-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #104562
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Desktop / Windows 11
App Component: Left Hand Navigation (LHN)
Action Performed:
Preconditions:
- The user has a workspace with "Travel" enabled and set up.
- The user has at least one upcoming trip already booked and confirmed.
- The user has enabled "travelApproval" in Account / Troubleshoot / Beta overrides
- Open the Expensify Web App and log in as the user from the Preconditions
- Go to Spend / Trips
- Observe the "Total" amount of any upcoming trip
- Click on the "View" button of this trip
- Click the back arrow button to close the trip room
- Observe the "Total" of this trip
Expected Result:
The "Total" amount of the trip should not change.
Actual Result:
The "Total" amount of the trip changes to 0 (zero).
Workaround:
Unknown
Platforms:
- Android: App
- Android: mWeb Chrome
- iOS: App
- iOS: mWeb Safari
- iOS: mWeb Chrome
- Windows: Chrome
- MacOS: Chrome Safari
Screenshots/Videos
Bug7299364_1793244221787.Expensify_PR104562_Web_Total.mp4
Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7299364
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
applause-bot commentedon Oct 29, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/6de705148eb45604c86fb1130f5492694a47a44da7287d870569742cc7c028b3
https://platform.applause.com/services/links/v1/external/3dfe063c602573bc465b7605f039b823cc2a0347052a451c6292f366cf531e92
melvin-bot commentedon Oct 29, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #104562
melvin-bot commentedon Oct 29, 2026
@stitesExpensify you have been assigned to this deploy blocker because you reviewed the offending PR: #104562
melvin-bot commentedon Oct 29, 2026
@suneox you have been assigned to this deploy blocker because you authored the offending PR: #104562
melvin-bot commentedon Oct 29, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 29, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
suneox commentedon Oct 29, 2026
I'm starting to look into this issue
MelvinBot commentedon Oct 29, 2026
Deploy Blocker Analysis
Causing PR: 104405 trips table (high confidence). It added the whole Spend > Trips table behind the
travelApprovalbeta, including every file that renders a trip row and its Total.Root cause: The trip row reads its Total from the trip room's ordinary
totalfield in the cached search results (TripListItemRow.tsx:74-79).SearchTriphas no field of its own for the trip total (SearchResults.ts:113). When the room's real report data is merged into that cache,totalbecomes the room's own value (0). The other trip fields survive, so the row stays but shows 0.Recommendation: Fix forward rather than revert. The feature is new, staging-only, and gated by a beta, so no production users are affected. Reverting would pull a 53-file PR that also touches shared Search code.
Suggested fix: Return the trip total in a dedicated field (for example,
tripTotal/tripCurrency), add it toSearchTrip, and read it inTripListItemRow.tsx. This needs a small backend change. No App-only option is clean.Investigation details
travelApproval,type:tripis the old expense search, so the bug can't appear. That's why production is N/A.getTripSectionscopies the trip-room report from the search snapshot into the row.isTripListItemTyperequirestravelerAccountID. The row staying visible means the cache was merged, not replaced.SEARCH_REPORTpanel (Search/index.tsx:688-694), andopenReportdoesn't touch the snapshot. The overwrite most likely comes from a server response or update that includesreport_<tripRoomID>. To confirm, comparesnapshot_<hash>.data.report_<tripRoomID>.totalbefore and after opening the room, and check which response changes it.DeployBlockerCashstays.view run
suneox commentedon Oct 29, 2026
@allgandalf This is a BE issue where the total field returns 0 when opening report details. Since this feature is still under a beta flag, I think this shouldn't be a deploy blocker.
OpenReport detail
CleanShot.2026-10-29.at.13.18.31.mp4
allgandalf commentedon Oct 29, 2026
@suneox
OpenReportis fine, it returns the room's owntotal(0). Onyx copies everyreport_update into the search snapshot, and the trip row readstotalfrom that same key. i'll addtripTotalandtripCurrencyon the backend so the row can read those. agree it shouldn't block, it's behind the betastitesExpensify commentedon Oct 29, 2026
Not a blocker, new feature behind a beta