Distance - Distance is not excluded when home and office address are used

[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.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100189
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Home address - East 45th Street, Los Angeles, CA, 90012, US
• Company address - 123 South Figueroa Street, Los Angeles, CA 90012
• Enable Distance rates.
• Enable Exclude usual commutes in Distance rates > Settings > Exclude commutes.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Track distance > Map.
4. Enter home address and company address.
5. Click Next.

Expected Result:

Distance will be excluded.

Actual Result:

Distance is not excluded.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7260774_1789519983929.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7260774

Issue Owner

Current Issue Owner: @thelullabyy

[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/51997a0c4fca6329055f0b553736551baac1181bc4f5e5dadcb7d851ddbc5f39

[MelvinBot]

Proposal

⚠️ Medium confidence. This is from code reading only — I could not reproduce it (test session broke) and I have no log or backend access to confirm the API response.

What is the root cause of that problem?

The "home and office" exclusion is computed on the server, not in the App. The App only applies it if the GetRoute response comes back carrying a commuterExclusionPreview object on the transaction. Nothing in App ever writes that field — it is only ever set to null (src/libs/actions/Transaction.ts:156, :471), and the GetRoute Onyx handlers only toggle the loading flag (:292 — "The route and failure are sent back via pusher in the BE").

If that object doesn't arrive — or arrives with hasExclusion: false — the exclusion is set to 0 and the whole function returns undefined (DistanceRequestUtils.ts:446-467), so the confirmation page renders the full distance and the full amount with no error and no hint — exactly what was reported.

For the steps as written (workspace chat → + → Track distance → Map), the App does send the right policyID, so I don't think the App picked the wrong workspace here. That points at the server side of the feature.

Investigation details

The gate. hasCommuterExclusionPreviewForPolicy (DistanceRequestUtils.ts:345) requires transaction.commuterExclusionPreview.policyID === policy.id. In the home-and-office branch (:446-459), a missing or non-matching preview means commuterExclusion = 0, which then hits the commuterExclusion <= 0 return at :465. This is the only path that can put an exclusion on a brand-new expense — the getUpdatedTransaction callers all require commuterExclusion > 0 to already exist.

One caveat worth checking against the video. If the member's policy really does hold commuterExclusions.method === 'homeAndOffice' and the preview simply never lands, the confirmation page is supposed to look pending — blank amount, "Pending" distance (useDistanceRequestState.ts:119-127). A normal, fully-populated amount instead means one of:

• (a) the preview did come back, with hasExclusion: false — i.e. the server decided this trip is not a commute (office/home address matching); or
• (b) the member's Onyx policy doesn't carry commuterExclusions.method = homeAndOffice at all, in which case the code falls through to the fixed-distance helper and quietly gets 0 (:365-376).

Whoever picks this up should say which one the screen recording shows — that single detail splits (a) from (b).

Two separate App-side defects found along the way (they don't explain the reported steps, but produce the same silent "nothing excluded" on other entry points):

1. Wrong policy on track / FAB / quick-action entries. usePolicyForTransaction.ts:57-60 swaps the chat's policy for policyForMovingExpenses when iouType === track, and it is undefined entirely when the flow starts from the global FAB or Search (no report). The preview's policyID then never matches, so the exclusion silently doesn't apply. Note the + menu dedupes by label and both entries read "Track distance", so the two flows are visually identical.
2. Possible GetRoute refetch loop. useFetchRoute.ts:41-45 keeps isCommuterExclusionPreviewStale true forever when the preview never matches; isLoadingRoute flipping back to false re-arms the effect, so the same transaction refetches its route repeatedly. Worth confirming in logs.

Also: the backup-transaction fetch at DynamicIOURequestStepDistance.tsx:164 still calls useFetchRoute with no policy, so a reverted edit restores a null preview.

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

The main fix is not in this repo, so I'm not proposing code for it. An internal engineer needs to confirm whether the GetRoute handler actually returns commuterExclusionPreview (with hasExclusion: true) for a home → office trip on staging, and whether office-address handling is complete — a paired backend change exists for this feature and a follow-up piece of it appears to still be open internally. If the preview isn't returned, nothing in App can fix this.

App-side, two things are worth fixing regardless:

1. Make the policy used for the preview match the policy the expense is actually headed for, so the policyID comparison can't fail on the track / FAB / Search entry points (usePolicyForTransaction). Pass the chat report's policy through for these flows, or fall back to it when policyForMovingExpenses is undefined.
2. Stop useFetchRoute re-firing forever when the preview never arrives — only treat the preview as stale once per set of waypoints, rather than on every render where it's missing.

What alternative solutions did you explore? (Optional)

I considered a pure App bug — the confirmation page failing to call the exclusion logic for a new draft. Ruled out: DistanceRequestController does run it for drafts, and the unit tests added in the PR explicitly assert undefined for "a home and office trip with no preview fetched yet", so the App behaves as designed when the preview is absent. I also checked isCommuterExclusionApplicableToRequestType and isPolicyExpenseChat — both pass for this flow, so neither is the blocker.

Related issues (not duplicates): Self DM distance in thread header shows commuter exclusion when it does not have exclusion and Profile - Commute exclusion description in Home address field does not appear after reset app are in the same feature area.

---

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

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: When creating a Track Distance expense, usePolicyForTransaction returns policyForMovingExpenses instead of the workspace's reportPolicy, so the route API call may receive the wrong (or no) policyID, preventing the backend from computing commuterExclusionPreview.hasExclusion = true, which causes getTransactionCommuterExclusionData to compute zero exclusion.
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES