[Due for payment 2026-03-19] Distance - The route between two points on map shows km instead of mi in 1:1 chat

[vincdargento]

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.35-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: https://test-management.browserstack.com/projects/2219752/folder/13176744/test-cases/41237168
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 15.7.4 Chrome, iPhone 15 iOS 26.2
App Component: Money Requests

Action Performed:

Preconditions: Tester's location is set to US

1. Sign in to ND
2. Create a USD workspace with the distance unit defaulted to miles
3. Open More features and enable Distance rates
4. Open Distance rates page > Settings > Unit > tap Kilometers
5. Navigate to the Inbox > FAB > Start chat > select another user
6. In the chat tap "+" button > Track distance > Map > enter valid waypoints
7. Observe the distance and unit on the green route line on the map

Expected Result:

The distance and unit on the map are shown in miles

Actual Result:

The route between two points on map shows km instead of mi when creating expense in 1:1 chat. The distance is calculated in kilometers. On the confirmation page it correctly shows miles.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @MarioExpensify (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.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When creating a distance expense in a 1:1 chat, the map route label shows the distance in kilometers ("km") instead of miles ("mi"), even though the user's workspace is configured for USD with miles. The confirmation page correctly shows miles, creating an inconsistency.

What is the root cause of that problem?

There are two interacting bugs:

1. Stale state in MapView prevents unit updates (primary cause)

Both MapView.tsx (line 59-65) and MapViewImpl.website.tsx (line 54-60) maintain a local distanceUnit state that syncs from the unit prop via a useEffect, but the guard condition is flawed:

const [distanceUnit, setDistanceUnit] = useState(unit);
useEffect(() => {
    if (!unit || distanceUnit) {
        return;
    }
    setDistanceUnit(unit);
}, [unit, distanceUnit]);

The condition if (!unit || distanceUnit) means: once distanceUnit has any truthy value, it will never accept updates from the unit prop. This useEffect was introduced to support the toggleDistanceUnit feature (allowing users to toggle km/mi on the map), but it also blocks legitimate prop updates.

If the component first renders with unit='km' (or unit=undefined, which falls back to km via the distanceUnit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_KILOMETERS default on line 74), and the correct unit='mi' arrives on a subsequent render, the state stays stuck at 'km'.

2. DistanceRequestFooter and the confirmation page use different policy/currency resolution

In DistanceRequestFooter.tsx (line 54-57), when policy is null (1:1 chat has no policyID), the code falls back to activePolicy (the user's last-used workspace via NVP_ACTIVE_POLICY_ID). If that workspace has been configured with kilometers as the distance unit, getDefaultMileageRate(activePolicy) returns a rate with unit='km'.

Meanwhile, the confirmation page uses DistanceRequestUtils.getRate() which falls back to getPersonalPolicy()?.outputCurrency ?? 'USD', and getDistanceUnit() defaults to DISTANCE_UNIT_MILES — a completely different fallback chain that produces the correct result.

The combination: on first render, the transaction may not yet have its customUnitRateID set (since Onyx.merge is async), so isCustomUnitRateIDForP2P returns false, the code uses defaultMileageRate(activePolicy) which gives unit='km', MapView locks in 'km', and even when the transaction data loads and the correct 'mi' unit is computed on re-render, MapView's useEffect guard prevents the update.

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

Fix the MapView useEffect in both MapView.tsx and MapViewImpl.website.tsx to properly sync the unit prop while still supporting user toggle:

Track whether the user has manually toggled the unit via a ref. Only ignore prop updates when the user has explicitly toggled; otherwise, always sync from the prop:

• Add a userToggledUnit ref (initialized to false) that gets set to true inside toggleDistanceUnit
• Change the useEffect to: if unit is truthy AND userToggledUnit is false, call setDistanceUnit(unit)
• This ensures the prop is always respected unless the user has manually toggled

Both MapView.tsx (native) and MapViewImpl.website.tsx (web) need this same fix.

Optionally, also change the fallback on line 74 from DISTANCE_UNIT_KILOMETERS to DISTANCE_UNIT_MILES to match the confirmation page's fallback behavior, though the useEffect fix is the primary solution.

What alternative solutions did you explore? (Optional)

1. Fix only the DistanceRequestFooter fallback chain to match the confirmation page's getRate() logic — this would address the initial incorrect value but wouldn't fix the stale state problem if the unit changes for any other reason.
2. Remove the local distanceUnit state entirely and always derive from the unit prop — simpler but would break the user toggle feature since there'd be no local state to toggle.
3. Use a usePrevious(unit) pattern to detect when the prop changes from the parent vs from the toggle — more complex and less readable than the ref approach.

---

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.

[MarioExpensify]

@MelvinBot which PR caused this regression?