[Due for payment 2026-05-20] [Due for payment 2026-05-20] [Due for payment 2026-05-18] [$250] Expense - Manual tab is not updated to new distance after adding a new waypoint.

[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: Pull Request QA execution
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"
6. Add a new waypoint.
7. Navigate to "Manual" tab.
8. Note that distance is not updated and original amount is still displayed.

Expected Result:

"Manual" tab should be automatically updated to new distance after adding a new waypoint to expense.

Actual Result:

"Manual" tab still shows original distance after a new waypoint is added to expense. Distance is only updated on manual tab after saving and reopening it.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148681_1778267176991.Edit_Dis_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053833521743843031
• Upwork Job ID: 2053833521743843031
• Last Price Increase: 2026-05-11

Issue Owner

Current Issue Owner: @aimane-chnaif

[melvin-bot]

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

[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 the Manual tab distance sync logic and is the direct cause of this regression. The issue is staging-only (new feature not in production), so a revert is the cleanest path to unblock the deploy. The PR author acknowledged in the PR body that a hide-the-tab fallback PR (#89976) exists if needed.

Assigned: @mukhrr (PR author), @aimane-chnaif @youssef-lr (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR is the cause). No label changes made.

Detailed Analysis

Evidence

• melvin-bot flagged PR fixed manual distance tab blockers #89858 immediately as the causing PR, consistent with my investigation.
• PR fixed manual distance tab blockers #89858 is listed (unchecked) in the StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-05-08 #90006), confirming it is in the current staging deploy and has not yet cleared QA.
• The bug is staging-only ("N/A - new feature, doesn't exist in prod"), which aligns with this being a new feature PR.
• The PR's stated test steps for issue [Due for payment 2026-05-18] [Due for payment 2026-05-15] Distance - Manual tab shows 0 mile after editing distance on Map tab #89842 exactly describe the broken scenario: "Add a new waypoint. Go to Manual tab. Verify Manual tab will show the new distance." — indicating the author was trying to fix this exact flow but introduced a regression.

Verification

• Affected files: src/pages/iou/request/step/IOURequestStepDistance.tsx and src/pages/iou/request/step/DistanceManualTabContent.tsx — both are modified by PR fixed manual distance tab blockers #89858.
• PR fixed manual distance tab blockers #89858 confirmed to touch IOURequestStepDistance.tsx (+283/-84 lines) and introduces the new DistanceManualTabContent.tsx component (76 additions).

Root Cause

PR #89858 added a useEffect in IOURequestStepDistance.tsx (lines 216-228) to push the recalculated route distance into the Manual tab input when waypoints change. The logic uses a lastSyncedRouteDistance ref to detect "real" waypoint-driven recalculations and skip the initial load.

The bug is in the guard condition at line 221:

if (lastSyncedRouteDistance.current == null || lastSyncedRouteDistance.current === routeDistance) {
    lastSyncedRouteDistance.current = routeDistance;
    return;
}

When the user adds a waypoint, getUpdatedTransaction sets routes.route0.distance to null (pending route fetch from backend). The effect runs with routeDistance == null, which triggers the early-return at line 217 and assigns lastSyncedRouteDistance.current = null. When the backend returns the new route and routeDistance becomes the new value, the guard at line 221 sees lastSyncedRouteDistance.current == null and skips the update — so manualNumberFormRef.current?.updateNumber() is never called, and the Manual tab keeps displaying the stale distance.

The fix would require preserving the pre-null value of lastSyncedRouteDistance across the pending (null) phase, so that the guard can correctly detect that a meaningful transition occurred when the route resolves.

[MelvinBot]

Proposal

What is the root cause of that problem?

When a waypoint is added/edited, saveWaypoint clears routes.route0.distance to null. The useEffect responsible for syncing the route distance into the Manual tab's form input tracks the last synced value via lastSyncedRouteDistance ref. When saveWaypoint nulls the distance, this ref becomes null. When the backend returns the new route with an updated distance, the guard on line 221 (lastSyncedRouteDistance.current == null) skips the update — it was designed to prevent overwriting a manually-entered distance after save, but it also prevents syncing a legitimately new route distance after waypoint changes.

Since NumberWithSymbolForm only reads its value prop on mount (via useState), the imperative updateNumber() call is the only mechanism to update the displayed value post-mount — and it never fires.

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

In IOURequestStepDistance.tsx, the useEffect guard at line 221 needs to distinguish between two null→value transitions:

1. Post-save re-fetch (should skip) — user saved a manual distance, the route re-fetch returns a value, but we want to keep the user's manual value.
2. Waypoint change (should sync) — user added/edited a waypoint on the Map tab, the route re-fetch returns a genuinely new distance that should be pushed to the Manual tab.

The fix: when routeDistance transitions from null to a new non-null value, only skip the updateNumber call if isManuallyEditing.current is true (which is already guarded on line 217). When isManuallyEditing is false (meaning the null came from saveWaypoint clearing the route, not from the user typing), allow the null→value transition to call updateNumber. Concretely, remove the lastSyncedRouteDistance.current == null portion of the guard on line 221, keeping only the lastSyncedRouteDistance.current === routeDistance equality check (which prevents re-syncing the same value).

The existing isManuallyEditing guard on line 217 already protects against overwriting user input, so the null check is redundant for that purpose.

What alternative solutions did you explore? (Optional)

An alternative would be to make NumberWithSymbolForm reactive to prop changes via a useEffect that syncs the value prop into currentNumber state. However, this would be a larger change with broader impact and could introduce unintended re-renders or conflicts with the existing imperative updateNumber mechanism.

Investigation details

Data flow when bug occurs:

1. User adds a waypoint → saveWaypoint() sets routes.route0.distance = null and customUnit.quantity = null
2. routeDistance becomes null, the useEffect sets lastSyncedRouteDistance.current = null and returns early (line 217-219)
3. getDistanceInMeters returns 0, so currentDistance falls back to the backup transaction's old distance (line 200-201)
4. Backend returns new route via Pusher → routeDistance becomes the new value (e.g. 5000m)
5. useEffect fires: lastSyncedRouteDistance.current == null → guard on line 221 returns early → updateNumber() never called
6. Manual tab keeps showing the stale backup distance

Key files:

• IOURequestStepDistance.tsx:216-228 — the buggy useEffect
• Transaction.ts:132-158 — saveWaypoint nulling the distance
• getDistanceInMeters.ts:10-19 — distance calculation priority

Possibly related: #90056 (distance tab RHP back button behavior) and #90057 (map receipt preview after rate change) were filed around the same time against the same PR.

---

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.