Distance - Distance field shows wrong expense when merging distance expense with exclusion

[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+sddd1jsods@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.
• Create two workspaces - A and B.
• Enable Distance rates in workspace A, then enable "Exclude a fixed distance per claim" in distance settings with 1 miles.

1. Go to staging.new.expensify.com
2. Create a distance expense with different waypoints in workspace A and B.
3. Go to workspace chat A.
4. Open the distance expense.
5. Click More > Merge.
6. Select distance expense from workspace chat B.
7. Select first merchant and second report > Continue.
   → Distance field shows the selected distance on confirm page.
8. Click back button.
9. Select second merchant and second report > Continue.

Expected Result:

Distance field will show the selected distance (second merchant) on confirm page.

Actual Result:

Distance field shows the wrong distance (first merchant) on confirm page when second merchant is selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7231160_1786469752419.31.mp4

View all open jobs on GitHub

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

[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/ca5d5661f2cb7baf1bbf57a55f61a4e8bc2d973f9677a5726933aaf400e4698c

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

Deploy Blocker Analysis

Offending PR: #93848 — "Implement workspace commuter exclusion" (the Exclude a fixed distance per claim feature from the repro). It's in the current staging deploy, merged 2026-08-10, staging-only / N/A in prod — timeline matches. Confidence: High.

Root cause: The merge flow copies the selected transaction's customUnit by reference and writes it via Onyx.merge, which deep-merges. PR #93848 added four optional exclusion fields to customUnit (commuterExclusion, reimbursableDistance, commuterExclusionType, commuterExclusionMethod). When you first select a merchant whose transaction has those fields, then go back and select a merchant whose transaction doesn't, the deep merge leaves the stale fields in place — so the confirm page keeps showing the first merchant's reimbursableDistance.

Recommended fix: Roll forward with a targeted fix (a revert of the ~70-file feature PR is disproportionate for this narrow merge edge case). In MergeTransactionUtils.ts:677, write customUnit with the four exclusion keys explicitly defaulted to null (then spread the selected transaction's customUnit over them) so Onyx.merge clears any stale values — mirroring the null-clearing pattern PR #93848 already established at MoneyRequest.ts:847-858.

Investigation details & evidence chain

Display path (why the stale value surfaces): When an exclusion is present, the confirm page renders customUnit.reimbursableDistance rather than the route distance:

• MoneyRequestView.tsx:613-618 → getCommuterExclusionDisplayData → getDistanceForDisplay (returns reimbursableDistance, ignoring the route distance).

The leak (verified at HEAD 1b2656d):

• MergeTransactionUtils.ts:677: updatedValues.customUnit = transaction?.comment?.customUnit; — copied wholesale by reference. Notably, the very next lines explicitly clear receipt/waypoints/routes to null when absent — customUnit is the one field that isn't cleared.
• MergeTransaction.ts:75-77: setMergeTransactionKey uses Onyx.merge (deep, recursive merge), so absent nested keys are not removed.
• The four optional exclusion fields: Transaction.ts:216-227.

Before #93848 these fields didn't exist, so deep-merging customUnit was harmless (route quantity/waypoints were always overwritten). The feature introduced fields that need explicit clearing, but the merge-selection path was missed.

Suggested fix shape:

updatedValues.customUnit = {
    commuterExclusion: null,
    reimbursableDistance: null,
    commuterExclusionType: null,
    commuterExclusionMethod: null,
    ...transaction?.comment?.customUnit,
};

A regression test that selects merchant A (with exclusion), goes back, re-selects merchant B (without exclusion), and asserts the merged customUnit.reimbursableDistance is cleared would lock this in.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/1b2656d631510c8650a3c9878f7335dbc3e01fcc/src/libs/MergeTransactionUtils.ts#L677) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.