[Due for payment 2026-05-20] [Due for payment 2026-05-18] Expense - Distance error remains after updating again to original amount.

[lanitochka17]

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.69-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: #89858
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Open any workspace chat.
3. Create a map distance expense.
4. Open the just created expense.
5. Click on "DIstance" > "Manual"
6. Edit the distance and save.
7. After being redirected to report, note that after some time, a "Distance exceeds the calculated route of XX" error appears.
8. Click on "DIstance" > "Map"
9. Click on any waypoint and on suggestions list, select the same waypoint again.
10. Click on "Save"
11. Note that when redirected to report, distance is updated to original value again, but error remains displayed.

Expected Result:

"Distance exceeds the calculated route of XX" error message should be cleared after updating distance to original value again.

Actual Result:

"Distance exceeds the calculated route of XX" error message remains visible after distance is updated to original value again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148658_1778265654385.Error_Waypoint.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @aimane-chnaif

[melvin-bot]

@youssef-lr recently merged #89858, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @Valforte (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #89858 - "fixed manual distance tab blockers" by @mukhrr (High confidence)
Related Issues: #83781

Recommendation: REVERT

PR #89858 introduced a regression in the submitWaypoints (map tab save) logic: when the user re-selects the same waypoints, the code short-circuits and navigates back without clearing the increasedDistance violation that was previously set by a manual distance edit. Reverting this PR is the cleanest fix.

Assigned: @mukhrr (PR author), @aimane-chnaif (approving reviewer), @youssef-lr (approving reviewer)
Labels: DeployBlockerCash kept (Frontend bug in Expensify/App). No label changes made.

📋 Detailed Analysis

Evidence

• The bug report directly references PR fixed manual distance tab blockers #89858 as the regression source (the melvin-bot comment auto-attributed it to this PR).
• PR fixed manual distance tab blockers #89858 substantially rewrote src/pages/iou/request/step/IOURequestStepDistance.tsx, adding new submitWaypoints and submitManualDistance callback functions.
• The bug reproduces as follows: editing distance manually (via the Manual tab) sets an increasedDistance violation on the transaction. Then switching to the Map tab and re-selecting the same waypoint triggers submitWaypoints. Inside submitWaypoints, line 524 checks haveWaypointAddressesChanged(transactionBackup?.comment?.waypoints, waypoints) — since the user re-selected the identical waypoint, this returns false, causing an early return at line 525-527 without calling updateMoneyRequestDistance. Because updateMoneyRequestDistance was never called, the violation-clearing logic in getUpdateMoneyRequestParams (which filters out INCREASED_DISTANCE violations optimistically) is never executed, so the error banner persists.
• Bug is staging-only (new feature, does not exist in production).

Verification

• Affected file: src/pages/iou/request/step/IOURequestStepDistance.tsx
• PR fixed manual distance tab blockers #89858 modifies this file (283 additions, 84 deletions confirmed by gh pr view).
• PR fixed manual distance tab blockers #89858 also modifies src/libs/actions/IOU/UpdateMoneyRequest.ts (73 additions, 12 deletions), which contains the violation-clearing logic for INCREASED_DISTANCE violations.
• The increasedDistance violation string ("Distance exceeds the calculated route of XX") is defined at src/languages/en.ts:8421 and resolved in src/libs/Violations/ViolationsUtils.ts:761.
• The clearing of INCREASED_DISTANCE violations happens at src/libs/actions/IOU/UpdateMoneyRequest.ts:1396-1400, which is only reached when updateMoneyRequestDistance is called — but this call is skipped when waypoints are unchanged.

Root Cause

In submitWaypoints (the map tab save handler added by PR #89858), when the user re-selects the same waypoint address, haveWaypointAddressesChanged returns false and the function returns early without making an API call. This is correct for the no-change case in isolation, but it fails to account for the fact that a prior manual distance edit may have set an increasedDistance violation that now needs to be cleared. The fix should either: (a) check for a pending increasedDistance violation and still call updateMoneyRequestDistance to trigger server re-evaluation, or (b) revert the PR so the old logic handles the case.