Distance-Rate with narrower range is not selected over Rate with wider range

[applause-bot]

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: v9.4.2-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: #92578
Email or phone of affected tester (no customers): applausetester+ag090626@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Money Requests

Action Performed:

Setup: Use an Expensifail account.
Create multiple distance rates on the workspace with different date bounds:
Rate A: "2025 mileage" — $0.50/mile, start: 2025-01-01, end: 2025-12-31
Rate B: "2026 mileage" — $0.60/mile, start: 2026-01-01, end: 2026-12-31
Rate C: "Default rate" — $0.55/mile, no dates (unbounded)
Rate D: $0.65/mile, start: 2026-06-01, end: 2026-06-30

1. Go to staging.new.expensify.com
2. Create a distance manual request with a date in June 2026 and manually change the rate to Rate B (2026 mileage)
3. Start a distance manual request
4. Enter the distance
5. Select a date in 2025
6. Verify that the rate is changed to Rate A (2025 mileage)
7. Change the date to any in June 2026

Expected Result:

The rate is set to Rate D, as the narrower range overrides the wider range.

Actual Result:

The rate is set to Rate B (2026 mileage).

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7176448_1781061040924.wrong_rate_selected.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

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

Proposal

What is the root cause of that problem?

When a date is changed on a distance request, IOURequestStepDate.tsx:129-137 calls getCustomUnitRateID to recompute the rate. That function honors the last selected rate first, and only falls back to the "best eligible (narrowest) rate" if the last selected one is ineligible:

DistanceRequestUtils.ts:488-499

In the repro, manually picking Rate B (2026 mileage) writes it as the last selected rate via setLastSelectedDistanceRate → MoneyRequest.ts:712. When the date is then changed to June 2026, Rate B is still eligible for that date (June 2026 ∈ 2026-01-01…2026-12-31), so the function short-circuits at line 491-492 and returns Rate B — it never reaches getBestEligibleRate, which would have selected the narrower Rate D (2026-06-01…2026-06-30).

This is a precedence conflict between two rules the PR introduced: "last selected rate respected when eligible" (PR Test 5) vs "narrower date range wins" (PR Test 3). The two only collide when the last-selected rate and a narrower rate both cover the chosen date — exactly this scenario.

Why the 2025 step works but June 2026 doesn't

• Date → 2025: last-selected Rate B is not eligible for 2025, so the short-circuit is skipped and getBestEligibleRate correctly returns Rate A.
• Date → June 2026: last-selected Rate B is eligible, so it short-circuits and wins before the narrower-range tie-break can run.

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

Decide which rule wins when a manually-selected rate and a narrower bounded rate both cover the date — this is a product decision the PR author should confirm. The two viable fixes in getCustomUnitRateID:

1. If "narrower range always wins on date change" is intended (matches the issue's Expected Result): when an expenseDate is provided, only honor the last-selected rate if it equals the best eligible rate — i.e. compute getBestEligibleRate first and prefer it over the last-selected short-circuit. Note this softens PR Test 5 when a narrower rate exists.
2. If the user's manual choice should be preserved, then the issue's Expected Result is wrong and the test should be updated — but that contradicts the deploy-blocker expectation, so option 1 is the likely correct path.

Recommended: option 1, gated on the date-change flow so it doesn't regress the "respect last selected" behavior for workspaces without overlapping bounded rates.

---

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