[Due for payment 2026-09-25] Add a shared helper to select a distance rate when the policy changes

[neil-marcellini]

(Neil's AI agent)

Part of the frontend tracking issue, which has the full plan and the rate-selection rules.

What

Add DistanceRequestUtils.getRateForPolicyChange({transaction, policy}), the app-side mirror of Auth's rate selection: value + currency + unit match against enabled rates valid for the expense date, then getBestEligibleRateOrPolicyDefault.

The date-range ranking is already implemented in getBestEligibleRate and matches Auth's getBestDistanceCustomUnitRateIDForDate, so this is mostly wiring.

The server is authoritative and the app only mirrors it for optimistic data, so add a comment on both implementations pointing at the other — the same convention getRate already uses.

No callers change in this PR, so it can land any time.

Dependencies

None.

Issue Owner

Current Issue Owner: @truph01

[melvin-bot]

@truph01 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[truph01]

@MelvinBot Post proposal

[MelvinBot]

Proposal

What is the root cause of that problem?

There is no App-side helper that mirrors Auth's rate-selection rule for a policy change.

The only helper available today is getDefaultMileageRate, which sorts the enabled rates by index and takes the first. It ignores the expense date, and it never asks whether the destination workspace already has a rate equivalent to the one the expense is using — so the move-expense auto-select block reprices the expense even when an identical rate exists on the destination.

The date-range half of the rule already exists in getBestEligibleRate / getBestEligibleRateOrPolicyDefault. The value/currency/unit match half does not exist anywhere, and nothing ties the two together.

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

Add getRateForPolicyChange to src/libs/DistanceRequestUtils.ts, directly below getBestEligibleRateOrPolicyDefault, and export it. No callers change, so this lands on its own.

getRateForPolicyChange({transaction, policy, currentRate?}) => MileageRate | undefined

It does this:

1. Expense date — getFormattedCreated(transaction), so a modified date wins over created.
2. Candidate rates — getMileageRates(policy) on the destination policy. Its default includeDisabledRates = false already drops disabled rates, and it stamps every rate's unit from the policy's distance custom unit attributes.unit — so the unit comparison in step 4 comes for free and correctly disqualifies the whole policy on a unit mismatch.
3. Current rate — use currentRate when the caller passes it. Otherwise, for a P2P expense (isCustomUnitRateIDForP2P), derive it from the transaction with getRateForP2P(getCurrency(transaction), transaction). If neither resolves, skip to step 5.
4. Matching rate — candidates where rate, currency, and unit all equal the current rate and isRateEligibleForDate passes. Rank ties with the same comparator getBestEligibleRate uses — pull that sort callback out into a named comparator and call it from both, so the tie-break rule stays in one place.
5. Fallback — getBestEligibleRateOrPolicyDefault(mileageRates, expenseDate, policy).
6. Return undefined when the winner has no customUnitRateID. This matters: when the destination policy has no enabled rates, getDefaultMileageRate still returns a fully shaped object with customUnitRateID: undefined, which a caller doing if (rate) would read as a successful selection. Normalizing to undefined here is what lets F3/F4 keep the customUnitOutOfPolicy violation.

Then add the cross-reference comment on this function and on the Auth helper, matching the convention already on getRate.

One deviation from the signature in the issue. The issue lists {transaction, policy}. A workspace distance expense does not store its rate value — only comment.customUnit.customUnitRateID, which resolves against the source policy — and DistanceRequestUtils holds no Onyx connections, so it cannot look that policy up itself. Making currentRate an optional third field keeps the documented two-argument call working for P2P expenses (where comment.customUnit.defaultP2PRate does carry the value) and lets F3/F4 pass the rate they have already resolved.

Tests to add in tests/unit/DistanceRequestUtilsTest.ts

• Value + currency + unit match beats the destination default.
• A disabled value-matching rate is not a match → falls through to the default.
• Currency mismatch → default.
• Unit mismatch → default (the whole destination policy is disqualified).
• A value-matching rate whose date range excludes the expense date → default.
• Two value-matching rates → narrower, more recent range wins.
• Destination policy with no enabled rates → undefined.
• P2P source expense, no currentRate passed → matches on defaultP2PRate.
• modifiedCreated takes precedence over created when picking the date.

What alternative solutions did you explore? (Optional)

Three alternatives, and why not

• Pass sourcePolicy instead of currentRate. The helper would then call getRate itself, which also needs personalPolicyOutputCurrency — a third argument every caller has already resolved. Passing the finished MileageRate is less plumbing.
• Return {mileageRate, isValueMatch}, mirroring the server helper's return. No App caller needs the flag: the Concierge copy states the new rate unconditionally, and the message is posted on any workspace change. Returning a bare MileageRate | undefined also keeps this a drop-in swap for getDefaultMileageRate at the F3 call site.
• Extend getCustomUnitRateID with a policy-change mode. It is built around lastSelectedDistanceRates for the creation flow, which is the wrong precedence here — the expense's own rate must win, not the one the user last picked.

---

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

---

view run · no recording available

[truph01]

@MelvinBot Implement this

[MelvinBot]

🤖 Draft PR created: #101080

Please mark it as "Ready for review" when it is ready for review.

What landed: DistanceRequestUtils.getRateForPolicyChange — matching rate (value + currency + unit, valid for the expense date) → getBestEligibleRateOrPolicyDefault → undefined. No callers change, so it can go in any time. F3 and F4 wire it up.

Two things worth a look in review:

1. The signature takes an optional third field, currentRate. The issue lists {transaction, policy}, but a workspace distance expense doesn't store its rate value — only comment.customUnit.customUnitRateID, which resolves against the source policy — and DistanceRequestUtils holds no Onyx connections, so it can't look that policy up itself. F3 and F4 both already hold the resolved rate. For a P2P expense the helper still derives it from comment.customUnit.defaultP2PRate, so the documented two-argument call works unchanged.
2. The Auth-side cross-reference comment is not in this PR, since it lives in a different repository. Someone with Auth access needs to add the pointer back to this helper.

Implementation details and test results

Changes — src/libs/DistanceRequestUtils.ts and tests/unit/DistanceRequestUtilsTest.ts only.

• Extracted the tie-break comparator out of getBestEligibleRate into compareRatesByDateSpecificity and reused it for the matching step, so the "narrowest and most recent date range" rule stays in one place. getBestEligibleRate behavior is unchanged.
• The helper returns undefined when the selected rate has no customUnitRateID. This is the guard flagged in the proposal: getDefaultMileageRate returns a fully shaped rate object with an undefined customUnitRateID when the policy has no enabled rates, which a caller doing if (rate) would read as a successful selection. Normalizing here is what lets F3/F4 keep the customUnitOutOfPolicy violation.
• Added the cross-reference comment noting the server is authoritative, matching the convention on getRate.

9 new unit tests: matching rate beats the default; disabled value-match falls through; currency mismatch falls through; unit mismatch disqualifies the whole policy; expired value-match falls through; narrower date range wins between two matches; no enabled rates returns undefined; P2P expense matches on defaultP2PRate with no currentRate passed; modifiedCreated wins over created.

Tests run:

Test	Result
npm test -- tests/unit/DistanceRequestUtilsTest.ts	✅ 61 passed (9 new)
npm test on the 4 other distance suites	✅ 44 passed
npm run typecheck	✅ passed
npm run lint-changed	✅ passed
npm run spell-changed	✅ passed
npm run lint (full repo)	⚠️ did not finish — exceeded the 10 minute limit in this environment. lint-changed runs the same linter over both changed files and passed.
npm run prettier	⚠️ not runnable — no prettier script exists in package.json at this commit.
npm run storybook -- --smoke-test --ci	⚠️ not run — no components or stories are touched.

---

view run · no recording available

[truph01]

@neil-marcellini I have a question for you #101080 (comment)