[Due for payment 2026-05-15] Distance - New map receipt is stuck at loading state after editing distance

[mitarachim]

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.68-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85493
Email or phone of affected tester (no customers): josdjnosdjionjsdonjisod@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a distance expense.
4. Open the expense.
5. Click Distance.
6. Add a new waypoint and save it.

Expected Result:

New map receipt will be generated after editing distance.

Actual Result:

New map receipt is stuck at loading state after editing distance.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7146583_1778108308900.2.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #85493

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 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:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #85493 introduced a pendingFields.merchant flag that is set on any waypoint/distance/rate edit (UpdateMoneyRequest.ts:990-998) but is deliberately excluded from clearedPendingFields so it persists past the API success response.

On API success, routes is cleared to null (UpdateMoneyRequest.ts:1309-1317), but pendingFields.merchant still evaluates to truthy. This keeps hasPendingReceiptRegeneration = true in ReportActionItemImage.tsx:126, which forces the ConfirmedRoute component to render. Since routes is now null and requireRouteToDisplayMap is true, ConfirmedRoute falls through to PendingMapView (the loading spinner) at ConfirmedRoute.tsx:89-112 and stays there until the Pusher push delivers the new receipt.source. If Pusher is slow or fails, the loading state persists indefinitely.

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

When shouldClearRoutes is true (routes are nulled on success), pendingFields.merchant should also be cleared so the component stops rendering the ConfirmedRoute/PendingMapView path and falls back to the existing receipt image. The Pusher push will later update receipt.source with the new map image.

In UpdateMoneyRequest.ts, when building successData, if shouldClearRoutes is true, include merchant: null in clearedPendingFields so the pending state doesn't outlive the route data it depends on.

What alternative solutions did you explore?

An alternative would be to preserve the optimistic routes data through the success response instead of clearing it (i.e., don't set routes: null when pendingFields.merchant is still active). This would let ConfirmedRoute continue rendering the map from coordinates until Pusher arrives. However, this risks showing stale route data if the waypoints changed, so clearing pendingFields.merchant in sync with routes is the cleaner fix.

Investigation details

Data flow leading to the bug:

1. User edits waypoints → updateMoneyRequestDistance() called
2. Optimistic data sets pendingFields.merchant = UPDATE and pendingFields.waypoints = UPDATE
3. API succeeds → success data clears pendingFields.waypoints (via clearedPendingFields) and sets routes: null
4. pendingFields.merchant is NOT cleared (deliberately excluded from clearedPendingFields)
5. ReportActionItemImage sees pendingFields.merchant → hasPendingReceiptRegeneration = true → showMapAsImage = true
6. Renders ConfirmedRoute with requireRouteToDisplayMap = true
7. ConfirmedRoute has no coordinates (routes was cleared) → renders PendingMapView (loading spinner)
8. Stuck until Pusher push arrives with new receipt.source

---

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.