[$250] Distance - Distance format on the report header changes after changing rate

[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.28-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: #74967
Email or phone of affected tester (no customers): isodjnosidjiojiojiso@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:

Precondition:

• Workspace has at least two distance rates.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual distance expense with 10 miles.
4. Open the expense.
   → Header shows amount for 10.00 mi @ rate.
5. Click Rate and select another rate.

Expected Result:

Distance on the report header will show 10.00 mi.

Actual Result:

Distance on the report header changes from 10.00 mi to 10 mi after changing rate.

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: @cristipaval

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028617526742827569
• Upwork Job ID: 2028617526742827569
• Last Price Increase: 2026-03-02
• Automatic offers:
• FitseTLT | Reviewer | 110642781

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

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

[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: #74967 - "Fix - [Unreported] Add distance rate to the distance expenses tracked in selfDM" by @FitseTLT (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

The PR introduced logic to handle distance rate changes for track expenses in selfDM, but has an inconsistency bug in how the distance is displayed after changing rates. The fix is straightforward - use the correct variables for display consistency.

Labels: No label changes needed. This is a Frontend bug that blocks the App deploy, so DeployBlockerCash should remain.

Detailed Analysis

Evidence

1. PR Fix - [Unreported] Add distance rate to the distance expenses tracked in selfDM #74967 added new functionality to allow changing distance rates for track expenses in selfDM
2. The melvin-bot comment confirms this PR was automatically assigned as the causing PR
3. Bug only reproduces on staging (where Fix - [Unreported] Add distance rate to the distance expenses tracked in selfDM #74967 is deployed) and affects a new feature that doesn't exist in production
4. The PR modified distance handling logic in MoneyRequestView.tsx and related files

Verification

In /home/runner/_work/App/App/src/components/ReportActionItem/MoneyRequestView.tsx lines 426-432:

const calculateFromTransactionData = isTrackExpense && !rate;
const distanceUnit = calculateFromTransactionData ? transaction?.comment?.customUnit?.distanceUnit : unit;
const distanceRate = calculateFromTransactionData ? (transactionAmount ?? 0) / (transaction?.comment?.customUnit?.quantity ?? 1) : rate;
let rateToDisplay = isCustomUnitOutOfPolicy
    ? translate('common.rateOutOfPolicy')
    : DistanceRequestUtils.getRateForDisplay(distanceUnit, distanceRate, currency, translate, toLocaleDigit, getCurrencySymbol, isOffline);
const distanceToDisplay = DistanceRequestUtils.getDistanceForDisplay(hasRoute, distance, unit, rate, translate, undefined, isManualDistanceRequest);

The Bug: Line 432 uses unit and rate for displaying distance, but line 431 correctly uses distanceUnit and distanceRate for displaying the rate. This inconsistency causes the distance format to change after rate selection because unit is derived from the new rate while distance is calculated from the transaction data with the old unit.

Root Cause

When a user changes the distance rate for a track expense:

1. Lines 427-428 correctly calculate distanceUnit and distanceRate from the transaction data for track expenses without a rate
2. Line 431 uses these values to display the rate correctly
3. Line 432 incorrectly uses the original unit and rate variables instead of distanceUnit and distanceRate

This causes a mismatch: the rate display uses one set of values while the distance display uses a different set, leading to the formatting inconsistency described in the bug (distance changes from "10.00 mi" to "10 mi").

The fix is simple: Line 432 should use distanceUnit and distanceRate instead of unit and rate for consistency with line 431.

[MelvinBot]

Proposal

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

After creating a manual distance expense with 10 miles in selfDM, the report header correctly shows "10.00 mi @ rate". However, when the user changes the rate to a different one, the distance format in the report header changes from "10.00 mi" to "10 mi" — losing the decimal places.

What is the root cause of that problem?

The root cause is a policy context mismatch between the optimistic update path and the rendering path, introduced by PR #74967.

During a rate change, the optimistic update in getUpdatedTransaction() (TransactionUtils/index.ts:785-800) correctly computes modifiedMerchant via getDistanceMerchant(), which always formats with 2 decimal places using getRoundedDistanceInUnits() → toFixed(2). This works because getUpdatedTransaction receives the correct workspace policy parameter.

During rendering, getMerchant() (TransactionUtils/index.ts:1134-1163) derives the policy from getPolicy(report?.policyID). For a selfDM expense, this returns the personal policy which has no customUnits. Because policy?.customUnits is falsy at line 1144, getMerchant does NOT recalculate the merchant with proper formatting — it falls through to returning the raw stored modifiedMerchant or merchant field at line 1162.

PR #74967 also changed getRate() (DistanceRequestUtils.ts:412-413) to return undefined for unreported expenses when the rate isn't found in available mileage rates (instead of falling back to defaultMileageRate). Combined with track distance expenses now getting real policy rate IDs instead of FAKE_P2P_ID, getMerchant called from display contexts can no longer resolve the rate to recalculate.

The API call only sends customUnitRateID in the params (not the merchant — see line 5110 of IOU/index.ts), so the server recalculates the merchant independently. If the server formats without preserving 2 decimal places (e.g. "10 mi" instead of "10.00 mi"), this overwrites the optimistic modifiedMerchant when the response is merged back into Onyx.

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

The fix should ensure getMerchant() in TransactionUtils/index.ts can properly recalculate the distance merchant for selfDM/unreported track expenses, rather than falling through to the raw stored value.

Specifically, in getMerchant() at TransactionUtils/index.ts:1143-1146, the condition should be expanded to also recalculate when the transaction is a distance request with a modifiedMerchant — even if the policy doesn't have customUnits. For selfDM distance expenses, the unit can be derived from getDistanceUnit (which falls back to the transaction's stored unit), and the rate from the mileage rate. The function already has unit and rate resolved at lines 1140-1141 — it just needs to use them when rate is available, regardless of whether policy?.customUnits is truthy.

Alternatively, the getRate call inside getMerchant could be updated to also check policyForMovingExpenses (the workspace policy associated with the expense) when the direct policy lookup fails for selfDM expenses.

What alternative solutions did you explore? (Optional)

1. Including merchant in the API params: Modify getUpdateTrackExpenseParams to always include the correctly-formatted merchant when sending rate changes. However, this duplicates server-side logic and doesn't fix the rendering mismatch.

2. Server-side fix: Ensure the server always formats distance with 2 decimal places. This would fix the symptom but not the underlying client-side issue where getMerchant can't recalculate for selfDM expenses.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.