Distance - Rate is not selected when distance expense is created offline

[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?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97517
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.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:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Go offline.
4. Create a manual distance expense.
5. Open the expense.
6. Click Rate.

Expected Result:

Rate will be selected when distance expense is created offline.

Actual Result:

Rate is not selected when distance expense is created offline.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7230454_1786393521642.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7230454

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022087931409581434781
• Upwork Job ID: 2087931409581434781
• Last Price Increase: 2026-08-13

Issue Owner

Current Issue Owner: @abdulrahuman5196

Issue Owner

Current Issue Owner: @abdulrahuman5196

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

[melvin-bot]

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

[melvin-bot]

@Valforte @abdulrahuman5196 you have been assigned to this deploy blocker because you reviewed the offending PR: #97517

[melvin-bot]

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

[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 (fix belongs in Expensify/App)
Causing PR: Prime suspect #97517 - "Optimistically add message for distance rate changes" by @Gonals — REFUTED (High confidence it is NOT the cause). True causing PR not yet identified.
Related Issues: #96206 (the issue #97517 fixed)

Recommendation: NEEDS INVESTIGATION

PR #97517 only touches the distance-rate edit/update flow, but this bug is purely in the create-then-view path (the Rate list never highlights the current rate). The auto-assignment was based on merge timing, not on code that this bug exercises. Keeping the blocker; the real root cause needs to be pinned before reverting anything.

Assigned: No change — no causing PR identified with sufficient confidence, so no new assignees added. (The three auto-assigned reviewers/author of #97517 appear misattributed; leaving them for now so they can weigh in.)
Labels: No change. Only DeployBlockerCash is present. This is a frontend App bug and it is not reproducible on production, so DeployBlockerCash must stay. No DeployBlocker (web) label is present.

📋 Detailed Analysis

Why #97517 is refuted

gh pr diff 97517 shows the change is confined to two update-only code paths:

• getUpdatedTransaction() in src/libs/TransactionUtils/index.ts — the branch that recalculates amount/merchant when a rate is changed (guard widened from !isFetchingWaypointsFromServer(transaction) to ... || hasLocallyKnownDistance(transaction)).
• getUpdateMoneyRequestParams() / getUpdateTrackExpenseParams() in src/libs/actions/IOU/UpdateMoneyRequest.ts — gating of the optimistic MODIFIED_EXPENSE report action when a rate is changed.

Both only run when a user edits an existing expense's rate. The repro here never changes the rate — it creates a distance expense and opens the Rate page to observe that no rate is highlighted.

Crucially, note in the same function that comment.customUnit.customUnitRateID is assigned unconditionally at TransactionUtils/index.ts L746-L747, outside the branch #97517 modified — so even the update flow's rate ID is unaffected by this PR.

Where the "selected rate" actually comes from

The checkmark on the Rate page is computed independently of anything #97517 touched:

• IOURequestStepDistanceRate.tsx L145-L166: isSelected = effectiveRateID === rate.customUnitRateID, where effectiveRateID = pendingRateID ?? currentRateID and currentRateID = getRateID(currentTransaction).
• getRateID() L2356-L2358 returns transaction?.comment?.customUnit?.customUnitRateID ?? FAKE_P2P_ID — it is never empty, so the getDefaultMileageRate(policy) fallback on L154 is effectively dead. If the transaction's customUnitRateID doesn't match any policy rate in the list, nothing is selected (matching the reported symptom).
• isOffline is used only inside selectDistanceRate (L246), not in the isSelected computation, so the display logic is network-independent.

Root Cause (direction, not yet a confirmed PR)

Because the selection logic is identical online and offline, the only thing that can differ between an online- and an offline-created expense is the optimistic value of comment.customUnit.customUnitRateID on the transaction:

• Online: the server response after creation updates/corrects the transaction, so any wrong optimistic rate is fixed within ~1s (likely why QA doesn't see it online / on production).
• Offline: no server response, so a wrong/mismatched optimistic customUnitRateID persists and the Rate page shows nothing selected.

The optimistic rate is assigned during creation via DistanceRequestUtils.getCustomUnitRateID() (L596-L656) → stored in the money-request init flow (src/libs/actions/IOU/MoneyRequest.ts around L372-L392). A regression in that optimistic-rate assignment (or in getBestEligibleRateOrPolicyDefault / getMileageRates), not in #97517, is the likely culprit. This is where investigation should focus.

Verification

• Affected file(s): src/pages/iou/request/step/IOURequestStepDistanceRate.tsx (selection display) and the optimistic creation path in src/libs/actions/IOU/MoneyRequest.ts + src/libs/DistanceRequestUtils.ts.
• Confirmed Optimistically add message for distance rate changes #97517 does not modify any of these files' relevant logic (it modifies getUpdatedTransaction and getUpdateMoneyRequestParams/getUpdateTrackExpenseParams — update flows only).

Suggested next step for the assignees

@Gonals / @Valforte / @abdulrahuman5196 — could you confirm whether reverting #97517 would even change this behavior? Based on the diff it should not. It would help to inspect the optimistic transaction.comment.customUnit.customUnitRateID of a distance expense created offline in a workspace chat and check whether it equals a real policy rate ID or falls back to FAKE_P2P_ID.