Distance - New rate is not selected after entering new rate when creating distance from self DM

[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.44-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: #85942
Email or phone of affected tester (no customers): sjndiojdsiodsojso@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. Click + > Track distance > Manual.
4. Enter amount > Next.
5. On confirm page, click Rate.
6. Click Upgrade > Got it, thanks.
7. Enter new rate and click Save.
8. Click Rate.

Expected Result:

After entering new rate, the new rate will be selected on confirm page.

Actual Result:

After entering new rate, the new rate is not selected. The previous rate is still selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7113018_1774455928460.1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #85942 - "Fix distance rate auto-selection when submitting from Self DM to workspace" by @MelvinBot (High confidence)
Related Issues: #82629, #85879

Recommendation: REVERT

PR #85942 should be reverted. While it fixed the submit-from-Self-DM-to-workspace flow (#85879), it broke the upgrade flow from Self DM. The fix was too narrow and did not account for the upgrade scenario where a new custom rate is created.

Labels: Keeping DeployBlockerCash (App PR caused the issue). DeployBlocker label is not present, so no action needed.

📋 Detailed Analysis

Evidence

PR #85942 modified src/components/MoneyRequestConfirmationList.tsx line 733, changing the guard condition from:

isMovingTransactionFromTrackExpense ||

to:

(isMovingTransactionFromTrackExpense && customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID) ||

This guard was intended to prevent the auto-rate-update effect (lines 726-740) from running when submitting from Self DM to workspace, allowing the rate validation effect (lines 518-557) to correctly show the "Rate not valid for this workspace" error.

However, this breaks the upgrade flow described in the bug report:

1. User creates distance expense in Self DM
2. Clicks "Upgrade" to create workspace with custom rates
3. Enters new rate and saves
4. Returns to confirmation page

At this point:

• setMoneyRequestDistanceRate has set customUnitRateID to the newly created rate ID (e.g., a generated UUID)
• lastSelectedRate has been saved with the new rate ID
• The auto-rate-update effect checks line 728: !["-1", CONST.CUSTOM_UNITS.FAKE_P2P_ID].includes(customUnitRateID)
• Since customUnitRateID is now the new rate ID (not "-1" or FAKE_P2P_ID), the condition is false
• The effect returns early without restoring lastSelectedRate
• Due to a race condition, the policy may not have the new rate yet, so the rate validation effect resets to the old default rate

Verification

Confirmed that PR #85942 modifies the exact code path affecting this flow:

• File: src/components/MoneyRequestConfirmationList.tsx
• Lines modified: 733 (the guard condition)
• The PR merge date (2026-03-24) aligns with when staging build 9.3.44-0 was created
• The bug only reproduces on staging (where PR Fix distance rate auto-selection when submitting from Self DM to workspace #85942 is deployed), not production

Root Cause

The guard condition (isMovingTransactionFromTrackExpense && customUnitRateID === CONST.CUSTOM_UNITS.FAKE_P2P_ID) is too specific. It only blocks the auto-rate-update effect when both conditions are true, but after creating a new rate in the upgrade flow, customUnitRateID is no longer FAKE_P2P_ID, so the guard does not apply. However, the effect still returns early at line 728 because customUnitRateID is not "-1" or FAKE_P2P_ID, preventing the restoration of lastSelectedRate.

The original fix in PR #84850 (which removed the isMovingTransactionFromTrackExpense guard entirely) was correct for the upgrade flow but broke the submit-from-Self-DM-to-workspace flow. PR #85942 tried to fix that regression but created a new bug in the upgrade flow.

[MelvinBot]

Proposal

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

When a user in Self DM creates a manual distance expense, clicks Rate on the confirm page, upgrades, and enters a new custom distance rate, the new rate is not selected on the confirm page. The default policy rate is shown instead.

What is the root cause of that problem?

CreateDistanceRatePage.tsx reads the transaction from the non-draft Onyx key:

const [transaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${getNonEmptyStringOnyxID(transactionID)}`);

But during the upgrade creation flow (Self DM → Track distance → Upgrade → Create rate), the transaction only exists as a TRANSACTION_DRAFT — the non-draft TRANSACTION entry doesn't exist yet because the expense hasn't been submitted.

When the user saves the new rate, setMoneyRequestDistanceRate(transaction, customUnitRateID, policy, true) is called with transaction = undefined. This function has a null guard that returns early without doing anything:

if (!currentTransaction) {
    Log.warn('setMoneyRequestDistanceRate is called without a valid transaction, skipping setting distance rate.');
    return;
}

Because the function exits early:

1. NVP_LAST_SELECTED_DISTANCE_RATES is not updated with the new rate ID
2. The transaction draft's customUnitRateID is not updated (it remains '-1' from the upgrade step)
3. Back on the confirm page, the auto-select useEffect (at MoneyRequestConfirmationList.tsx:726) resolves '-1' to lastSelectedRate, which is the policy's default mileage rate — not the newly created rate

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

In src/pages/workspace/distanceRates/CreateDistanceRatePage.tsx, read from TRANSACTION_DRAFT instead of TRANSACTION when in the distance rate upgrade flow (isDistanceRateUpgrade is truthy). This way, setMoneyRequestDistanceRate receives a valid transaction object and can properly update both the draft and NVP_LAST_SELECTED_DISTANCE_RATES with the new rate.

The simplest approach: read from both Onyx keys and prefer the draft (matching the pattern used by IOURequestStepConfirmation.tsx):

const [existingTransaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${getNonEmptyStringOnyxID(transactionID)}`);
const [draftTransaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${getNonEmptyStringOnyxID(transactionID)}`);
const transaction = isDistanceRateUpgrade ? (draftTransaction ?? existingTransaction) : existingTransaction;

What alternative solutions did you explore? (Optional)

An alternative would be to modify setMoneyRequestDistanceRate to accept a transactionID string directly instead of requiring the full transaction object, so it could write to the draft even when the transaction object is unavailable. However, the transaction object is also needed for distance unit conversion logic, so reading the correct Onyx source in CreateDistanceRatePage is the cleaner fix.

---

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.