[Due for payment 2026-09-18] Distance - Original and Removed distance shows wrong amount after changing unit and rate

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.52-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: #93848
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.
• Enable Distance rates.
• Create one more distance rate in workspace settings > Distance rates.
• Enable "Exclude a fixed distance per claim" in distance settings with 1 miles.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a map distance expense.
4. Go to workspace settings > Distance rates.
5. Click Settings > Unit.
6. Change to another unit.
7. Go back to workspace chat and open the expense.
8. Click Rate.
9. Select another rate.

Expected Result:

After changing unit and rate, Original distance and Removed commuter distance will show the correct value.

Actual Result:

After changing unit and rate, Original distance and Removed commuter distance show different value, then it shows the correct value.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7230588_1786405263684.18.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7230588

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/edd33c377ef1de3dd321426271dbfe49e481683eb8a87d24f502f25b3e2956e1

[melvin-bot]

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

[melvin-bot]

@Gonals @marufsharifi you have been assigned to this deploy blocker because you reviewed the offending PR: #93848

[melvin-bot]

@fedirjh you have been assigned to this deploy blocker because you authored the offending PR: #93848

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #93848 - "Implement workspace commuter exclusion (App-side slice)" by @fedirjh (High confidence)
Related Issues: N/A

Recommendation: DEMOTE

This is a transient, self-correcting UI flicker on a brand-new feature that does not exist in production — the Original / Removed commuter breakdown briefly renders a stale value (old unit/rate) and then settles on the correct value, so it is cosmetic and not worth blocking the whole deploy. If the deploy team prefers to keep it blocking, the fix should be a targeted roll-forward, not a revert of this 70+ file feature PR (which also has a backend counterpart already merged).

Assigned: @fedirjh (PR author), @Gonals and @marufsharifi (reviewers) — already assigned by Melvin from this PR; no change needed.
Labels: No label change. Keeping DeployBlockerCash in place — an App PR caused this, so I am not auto-removing the App blocker. The actual demotion (label removal) is deferred to the deploy manager. DeployBlocker (Web) is not present and should not be added; the fix is entirely in Expensify/App.

📋 Detailed Analysis

Evidence

• PR [Payment due @marufsharifi] [Commuter Mileage Exclusion] [R1] Display and enforce fixed distance exclusions #93848 introduces the entire commuter-exclusion "Original / Removed commuter distance" breakdown that this bug is about. It is listed in the current StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-08-10 #98179, item 73) and merged 2026-08-10, matching the reported version 9.4.52-0.
• The bug is staging-only / N/A in production precisely because the feature is new and does not exist in prod — consistent with the PR being the origin.
• The reproduction (change the workspace distance unit, then change the expense rate) exercises exactly the unit/rate conversion + commuter re-derivation logic that this PR added. The PR's own offline-test notes even call out avoiding "flicker" when values are reconciled, confirming this is the affected code path.

Verification

The affected area is the commuter breakdown rendered on the expense detail view. Confirmed the PR modifies every file in the code path:

• src/components/ReportActionItem/MoneyRequestView.tsx — renders the breakdown (L613-L618).
• src/libs/DistanceRequestUtils.ts — getCommuterExclusionDisplayData (L327-L338) and getDistanceDisplayDetailsWithCommuter (L443-L468).
• src/libs/TransactionUtils/index.ts — getUpdatedTransaction re-derives the breakdown on rate change (L746-L828).

All three files are in PR #93848's file list. The bug appeared only after this PR shipped to staging.

Root Cause

The Original / Removed commuter values are stored on the transaction (comment.customUnit.commuterExclusion, comment.customUnit.reimbursableDistance, comment.customUnit.distanceUnit) and the detail view renders them directly:

• MoneyRequestView.tsx L613-L618 reads distanceUnitValue = transaction.comment.customUnit.distanceUnit and passes transaction.comment.customUnit into getCommuterExclusionDisplayData.
• getDistanceDisplayDetailsWithCommuter then computes originalDistance = reimbursableDistance + commuterExclusion (DistanceRequestUtils L459) and formats it in distanceUnitValue.

These stored fields are recomputed for a rate/unit change in getUpdatedTransaction (TransactionUtils L746-L828): it converts quantity, updates distanceUnit, and re-derives commuterExclusion / reimbursableDistance via getTransactionCommuterExclusionData, which then lands as an optimistic Onyx write and is later confirmed by the server (UpdateMoneyRequestDistanceRate).

Because the transaction being edited was created before the unit was changed, its stored customUnit still holds the old-unit breakdown at the moment the rate is changed. During the change there is a brief render window where the breakdown is still derived from the pre-conversion (old unit/rate) customUnit values before the recomputed optimistic/server values land — producing the momentarily wrong Original / Removed distance that then corrects itself. The final displayed value is correct; only the intermediate frame is stale, which is why this is a cosmetic flicker rather than a data-integrity bug.