Distance - Distance and Rate revert to old unit after reopening distance expense

[nlemma]

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.16-4
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #81017
Email or phone of affected tester (no customers): sjdoinsjodjsosjosjoi@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:

• Enable Distance rates in workspace settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a manual distance expense.
4. Go to workspace settings > Distance rates.
5. Click Settings > Unit.
6. Change it to another unit.
7. Open the distance expense from Step 3.
8. Click Distance.
9. Without changing anything, click Save.
   → Distance and Rate are updated to the new unit. Amount does not update despite the distance rate is changed,
10. Close the distance expense.
11. Reopen the distance expense.
    → Distance and Rate revert to the previous unit.

Expected Result:

In Step 9, when Distance and Rate are updated to the new unit, Amount should also update.
In Step 11, when distance expense is opened, the new Distance and Rate unit will not change,

Actual Result:

In Step 9, when Distance and Rate are updated to the new unit, Amount does not update.
In Step 11, when distance expense is opened, the new Distance and Rate unit revert to previous unit.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7073746_1770738017202.16.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @garrettmknight (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: #81017 - "Fix updates of distance and distance units when changing expense recipients" by @GCyganek (High confidence)
Related Issues: Fixed #80661

Recommendation: REVERT

PR #81017 introduced changes to the setCustomUnitRateID() function that cause distance unit and quantity updates to not persist correctly when reopening distance expenses after workspace settings changes.

Labels: Keeping DeployBlockerCash label (frontend bug blocks App deploy). This issue is only reproducible on staging, but it involves App code that needs to be reverted or fixed.

Detailed Analysis

Evidence

PR #81017 was merged on 2026-02-06 and is included in the staging deploy 9.3.16-4. The issue:

• Is reproducible on staging only (not production)
• Is directly related to distance unit handling
• Was caught during regression testing as a side effect of PR Fix updates of distance and distance units when changing expense recipients #81017

The PR modified setCustomUnitRateID() in /home/runner/_work/App/App/src/libs/actions/IOU/index.ts to update transaction.comment.customUnit.distanceUnit and transaction.comment.customUnit.quantity whenever the rate ID changes.

Verification

Files affected by the bug:

• /home/runner/_work/App/App/src/libs/actions/IOU/index.ts - Contains the setCustomUnitRateID() function
• /home/runner/_work/App/App/src/components/MoneyRequestConfirmationList.tsx - Calls setCustomUnitRateID() with transaction and policy params

PR #81017 modifies these exact files:

src/libs/actions/IOU/index.ts
src/components/MoneyRequestConfirmationList.tsx

The PR changes the signature of setCustomUnitRateID() from:

function setCustomUnitRateID(transactionID: string, customUnitRateID: string | undefined)

to:

function setCustomUnitRateID(transactionID: string, customUnitRateID: string | undefined, transaction: OnyxEntry<OnyxTypes.Transaction>, policy: OnyxEntry<OnyxTypes.Policy>)

Root Cause

The PR introduced logic that automatically updates distanceUnit and quantity in the transaction draft when setCustomUnitRateID() is called. However, this creates issues:

1. Step 9 Issue: When the user clicks "Save" on the distance field without changing values, the MoneyRequestConfirmationList component calls setCustomUnitRateID() which updates the distance unit and quantity, but the amount calculation does not trigger because the actual distance value in meters has not changed.

2. Step 11 Issue: When reopening the distance expense, setCustomUnitRateID() is called again during the useEffect in MoneyRequestConfirmationList (lines 348-349 of the PR diff). This overwrites the transaction's stored distanceUnit and quantity values. Since the transaction already has these values set from a previous save, the function updates them again based on the current policy, causing them to revert to whatever is stored in the transaction rather than what the policy now specifies.

The fundamental issue is that the PR made setCustomUnitRateID() responsible for both:

• Setting the rate ID (its original purpose)
• Updating distance units and quantities to match the new rate (new behavior)

This dual responsibility creates confusion about when and how distance values should be updated, especially for existing expenses where the unit has changed in workspace settings but the transaction still has old unit values stored.