[Due for payment 2026-05-18] [Due for payment 2026-05-15] Distance field shows converted distance with old unit after changing unit and edit offline

[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?: 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: #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. Go to workspace settings > DIstance rates.
5. Click Settings > Unit.
6. Select a different unit.
7. Open distance expense in Step 3.
8. Go offline.
9. Click Distance > Go to Manual tab.
10. Click Save.

Expected Result:

Distance field will show the converted distance with new unit.

Actual Result:

Distance field shows the converted distance with old unit.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7146610_1778110193124.8.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @aimane-chnaif

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #85493 - "Allowing distance to be edited while editing" by @mukhrr (High confidence)
Related Issues: #83781 (the issue this PR was fixing)

Recommendation: REVERT

PR #85493 introduced the manual distance editing tab for distance expenses. The bug in the offline unit-conversion scenario is a direct consequence of logic introduced by this PR, and the PR is the only staging-only change that touches the distance editing flow.

Assigned: @mukhrr (PR author), @aimane-chnaif (approving reviewer), @youssef-lr (approving reviewer)
Labels: DeployBlockerCash kept (Frontend/App bug). DeployBlocker should be removed — no backend fix is needed.

Detailed Analysis

Evidence

• The issue title directly references PR Allowing distance to be edited while editing #85493 in the test name/link (https://github.com/Expensify/App/pull/85493).
• The melvin-bot assigned the PR author because this PR is already associated with the issue.
• PR Allowing distance to be edited while editing #85493 merged on 2026-05-06 and version 9.3.68-0 (the affected staging version) includes this PR per the StagingDeployCash checklist.
• The bug is staging-only ("Reproducible in production? N/A - new feature, doesn't exist in prod"), confirming the cause is a newly-introduced feature.
• The affected flow — distance expense editing via a manual tab with offline unit conversion — is entirely new behavior introduced by PR Allowing distance to be edited while editing #85493.

Verification

Affected files introduced/modified by PR #85493:

• src/pages/iou/request/step/IOURequestStepDistance.tsx — Added the tab navigator with Map and Manual tabs, added distanceUnit / currentDistance / submitManualDistance logic.
• src/pages/iou/request/step/DistanceManualTabContent.tsx — New file, the manual distance input tab.
• src/libs/TransactionUtils/getDistanceInMeters.ts — Reordered priority: comment.customUnit.quantity now takes precedence over routes.route0.distance.
• src/libs/actions/IOU/UpdateMoneyRequest.ts — Complex changes to getUpdateMoneyRequestParams including waypoint suppression logic and route-clearing behavior.

The bug reproduces at the intersection of two things this PR changed:

1. currentDistance computation uses the new unit but getDistanceInMeters uses the old currentTransactionDistanceUnit: In IOURequestStepDistance.tsx (lines 192–198), distanceUnit comes from DistanceRequestUtils.getRate({useTransactionDistanceUnit: false}), which reflects the new policy unit. But getDistanceInMeters is called with currentTransactionDistanceUnit ?? distanceUnit — if currentTransactionDistanceUnit is set (the old unit stored on the transaction), it uses the old unit to interpret comment.customUnit.quantity. The result (distanceInMeters) is then converted back into the new distanceUnit for display. However, when offline, the policy rate may not be resolvable (rate is undefined), causing getRate to fall back to the transaction-stored unit. This means the displayed currentDistance can be the unconverted old-unit value.

2. Offline path in submitManualDistance reads currentDistance (which was pre-populated from the old unit's quantity), rounds it, and sends it as the new distance in the new unit: If the user simply presses Save without editing the value, distanceAsFloat equals currentDistance which represents the old unit's number — not the correctly converted value. The backend then stores the wrong quantity.

The offline constraint (step 8 of the reproduction) ensures the policy rate lookup fails, triggering the fallback code path that exposes the unit mismatch.

Root Cause

IOURequestStepDistance.tsx computes currentDistance by calling getDistanceInMeters(currentTransaction, currentTransactionDistanceUnit ?? distanceUnit). When the workspace unit was changed (e.g., miles → km), currentTransactionDistanceUnit still holds "mi" (the old unit from the stored transaction), so getDistanceInMeters interprets comment.customUnit.quantity as miles and converts that to meters. The meters value is then re-converted to km for display via convertDistanceUnit(distanceInMeters, distanceUnit). While this looks correct mathematically, the offline fallback in getRate (where useTransactionDistanceUnit: false but offline means the policy rate is unavailable) can return the transaction-stored unit as a fallback, causing distanceUnit to equal currentTransactionDistanceUnit. In that case the displayed distance is the raw quantity value in the old unit, and pressing Save persists that unconverted value as the new distance in the new unit.