[HOLD Auth/pull/20597] Distance value displays route distance instead of manually updated distance

[neil-marcellini]

Problem

When a user manually updates the distance value for a distance expense in Expensify Classic, the New Expensify app still displays the original route distance instead of the updated value.

Root Cause

In src/libs/TransactionUtils/getDistanceInMeters.ts, the function checks transaction.routes.route0.distance first and returns it if present. Only if routes are empty does it fall back to transaction.comment.customUnit.quantity.

When UpdateTransaction is called (e.g. from Expensify Classic to manually update the distance), it updates comment.customUnit.quantity but does not clear routes.route0.distance. Since the route distance has priority, the stale route value is displayed instead of the manually updated value.

Reproduction Steps

1. Create an expense on New Expensify using Track distance and the map
2. Enter any two waypoints and save the expense
3. Open the same expense on Expensify Classic
4. Manually update the distance value and save the expense
5. Reopen the expense on New Expensify
6. Observe the distance field still shows the original route distance, not the manually updated value

Expected Behavior

The distance field should display the manually updated value from comment.customUnit.quantity.

Proposed Fix

Reverse the priority in getDistanceInMeters: prefer comment.customUnit.quantity when it is set, and only fall back to routes.route0.distance when there is no custom unit quantity.

Related

• Expensify/Web-Expensify#51378 (comment)

Issue Owner

Current Issue Owner: @FitseTLT

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037585935439351322
• Upwork Job ID: 2037585935439351322
• Last Price Increase: 2026-03-27

[MelvinBot]

Proposal

What is the root cause of that problem?

The function getDistanceInMeters checks transaction.routes.route0.distance first and returns it immediately if present. It only falls back to comment.customUnit.quantity when routes are empty.

The lifecycle for a map-based distance expense is:

1. During creation: the backend populates routes.route0.distance via Pusher after the GetRoute API call, while quantity is explicitly set to null
2. On success: routes is cleared to null and from that point forward quantity holds the authoritative distance value

The bug occurs when a user edits the distance in Expensify Classic — the backend updates comment.customUnit.quantity with the new value, but routes.route0.distance (cached locally in Onyx from the original map route) is never cleared. Since getDistanceInMeters gives routes higher priority, the stale route distance wins over the manually updated quantity.

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

Reverse the priority in getDistanceInMeters to prefer comment.customUnit.quantity over routes.route0.distance:

1. src/libs/TransactionUtils/getDistanceInMeters.ts — Check quantity first; fall back to routes.route0.distance only when quantity is not set.

This is safe because during the creation flow, quantity is null (falsy), so the function naturally falls through to routes.route0.distance. After the expense is saved and routes is cleared, quantity takes over — same as today. The only behavior change is for the bug scenario: when both fields are present, the explicitly-set quantity now wins over the stale route cache.

Note: DistanceRequestFooter calls getDistanceInMeters(transaction, undefined) — passing undefined as the unit. The quantity branch requires a valid unit for conversion (&& unit), so the footer will continue to use routes.route0.distance for its map display, which is correct behavior since the footer only needs the route geometry distance.

What alternative solutions did you explore? (Optional)

• Clearing routes when a manual distance update is received: This would require changes on the backend/Classic side to propagate the route clearing when UpdateTransaction modifies the distance. While more thorough, it's a larger cross-platform change for what is fundamentally a priority/display issue in NE.
• Clearing routes in getUpdatedTransaction: We could null out routes.route0.distance in getUpdatedTransaction when a distance change comes in. This would work but is more fragile — the priority fix in getDistanceInMeters is the more robust solution since it handles all paths that read the distance.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @FitseTLT (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022037585935439351322

[neil-marcellini]

@jnowakow I did some manual testing for this on dev and I noticed that the transaction update was not pushed to App. I think we need your backend PR to go live before that will work.

[Auth] Revert "Revert "Push onyx updates from UpdateTransaction""