Distance - Confirm page auto selects distance rate instead of showing "Rate not valid"

[lanitochka17]

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: 9.3.41-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: #84850
Email or phone of affected tester (no customers): sodjnsojosidjosij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual distance expense.
4. Click Submit it to someone.
5. Select workspace chat.

Expected Result:

Confirm page will show the same amount, distance and rate as the distance expense, with "Rate not valid for this workspace. Please select an available rate from the workspace." error.

Actual Result:

Confirm page auto selects workspace distance rate.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7107763_1773958564490.11.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #84850 - "Fix distance rate not selected after creating new rate from self DM" by @MelvinBot (High confidence)
Related Issues: #82629 (original issue that PR #84850 was fixing)

Recommendation: REVERT

PR #84850 removed a guard (isMovingTransactionFromTrackExpense) from a useEffect hook that auto-selects distance rates. This fix was too broad and unintentionally changed the behavior when submitting regular distance expenses from Self DM to workspace chats.

The PR correctly fixed issue #82629 (new custom rates not being selected after upgrade flow), but introduced this regression for the standard Self DM submission flow.

Labels: This is a frontend bug caused by an App PR. The current label DeployBlockerCash is correct - no label changes needed.

Detailed Analysis

Evidence

PR #84850 modified src/components/MoneyRequestConfirmationList.tsx by removing the isMovingTransactionFromTrackExpense condition from a useEffect hook (lines 705-718) that auto-selects distance rates based on lastSelectedRate.

The PR was merged on 2026-03-19 at 17:35:07 (within this staging deploy cycle). The bug is reproducible on staging but not production, confirming it was introduced in this release.

Verification

The modified file src/components/MoneyRequestConfirmationList.tsx is directly responsible for the confirm page behavior when submitting expenses. The PR changed only this one file, removing 2 lines and adding 1 line.

Root Cause

When a user creates a distance expense in Self DM, the transaction has customUnitRateID = CONST.CUSTOM_UNITS.FAKE_P2P_ID (a special marker for P2P rates to avoid policy rate violations).

Before PR #84850:

• The useEffect at lines 705-718 was blocked by the isMovingTransactionFromTrackExpense guard
• The validation effect (lines 500-526) would check if the P2P rate was valid for the workspace
• If no matching rate existed, it would show the error "Rate not valid for this workspace"

After PR #84850:

• The useEffect at lines 705-718 now runs even when isMovingTransactionFromTrackExpense is true
• Because customUnitRateID === FAKE_P2P_ID, the condition at line 707 passes
• The effect auto-selects lastSelectedRate (the workspace default rate or last used rate for that policy)
• This auto-selection happens instead of showing the validation error

The fix for issue #82629 (creating new custom rates via upgrade flow) was too broad. It needed to allow the effect to run for the upgrade flow specifically, but NOT for regular Self DM submissions. Removing the entire guard affected both scenarios.

Expected Fix

The fix should differentiate between:

1. New custom rate creation flow (should auto-select the newly created rate) - what [Due for payment 2026-03-30] [$250] Distance - New rate is not selected after entering new rate when submitting distance from self DM #82629 addressed
2. Regular Self DM submission flow (should validate and show error if rate invalid) - what Distance - Confirm page auto selects distance rate instead of showing "Rate not valid" #85879 reports

A more targeted approach would preserve the guard for regular submissions while allowing the rate selection for the new rate creation scenario.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user creates a manual distance expense in their self DM and then clicks "Submit it to someone" targeting a workspace chat, the confirm page auto-selects the workspace's distance rate instead of showing the expected "Rate not valid for this workspace. Please select an available rate from the workspace." error.

What is the root cause of that problem?

PR #84850 removed the isMovingTransactionFromTrackExpense guard from the auto-rate-update useEffect in MoneyRequestConfirmationList.tsx (line ~705-718). This effect fires when customUnitRateID is '-1' or FAKE_P2P_ID and auto-sets it to lastSelectedRate (the workspace's default/last-used rate).

The flow that breaks:

1. User tracks a distance expense in self DM — the transaction gets customUnitRateID = FAKE_P2P_ID
2. User clicks "Submit it to someone" and selects a workspace (action = SUBMIT, so isMovingTransactionFromTrackExpense = true)
3. The auto-rate-update effect (line 705) fires because FAKE_P2P_ID matches its trigger condition and the isMovingTransactionFromTrackExpense guard no longer blocks it
4. It calls setCustomUnitRateID(transactionID, lastSelectedRate, ...), silently replacing the invalid P2P rate with a valid workspace rate
5. The rate validation effect (line 500) then sees a valid rate and clears the error instead of showing "Rate not valid"

Before PR #84850, the isMovingTransactionFromTrackExpense guard on the auto-rate-update effect prevented step 3 from firing, allowing the rate validation effect to correctly detect the incompatible FAKE_P2P_ID rate and show the error.

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

Re-add the isMovingTransactionFromTrackExpense guard to the auto-rate-update effect, but only for the FAKE_P2P_ID case. The key insight is that the two scenarios use different sentinel values:

• Upgrade flow (PR Fix distance rate not selected after creating new rate from self DM #84850's original fix): Uses customUnitRateID = '-1' as sentinel
• Submit-to-workspace flow (this regression): Uses customUnitRateID = FAKE_P2P_ID

In the auto-rate-update effect at src/components/MoneyRequestConfirmationList.tsx (line ~705), add back a targeted guard: when isMovingTransactionFromTrackExpense is true AND customUnitRateID is FAKE_P2P_ID, early-return (block the effect). When customUnitRateID is '-1' (upgrade flow), allow the effect to proceed regardless of isMovingTransactionFromTrackExpense.

Also re-add isMovingTransactionFromTrackExpense to the dependency array.

This preserves the fix for the original issue (#82629) while restoring the correct "Rate not valid" behavior for the submit-to-workspace flow.

What alternative solutions did you explore? (Optional)

An alternative would be to fully revert PR #84850 and find a different approach to the original issue (#82629). However, since the two flows use distinct sentinel values ('-1' vs FAKE_P2P_ID), a targeted guard is cleaner and addresses both issues simultaneously.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[aldo-expensify]

cc @jjcoffee