Submit workspace - Rate not valid error remains after selecting default rate

[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: 9.4.34-11
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: #94319
Email or phone of affected tester (no customers): applausetester+sdoisdddndos@applause.expensifail.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:

Precondition:

• Log in with Expensifail account.
• Account has no workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a distance expense.
4. Click Submit to my employer.
5. On confirm page, click Rate.
6. Select Defaut rate.

Expected Result:

Rate not valid error will not show up after selecting default rate.

Actual Result:

Rate not valid error remains after selecting default rate.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7209128_1784131547889.14.mp4

View all open jobs on GitHub

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

[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/7789c7c40f62075b1214b7396c4c95b7cb9b29fd1ee8c40f2a2ac9d559cef85c

[melvin-bot]

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

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

[iwiznia]

Not sure I get the connection between that PR and this bug... but we did touch something related to custom unit rates. @abzokhattab can you please check?

[MelvinBot]

Proposal

What is the root cause of that problem?

When you "Submit to my employer" with no existing workspace, PR #94319 creates a new submit2026 workspace as a draft (it lives in POLICY_DRAFTS, not POLICY, until it syncs). The confirmation screen renders the distance rate from that draft, but the rate-validation effect reads the rate list from a policy that resolves to undefined for a draft — so the invalidRate error can never clear, no matter which rate you pick.

The disconnect is that the confirmation list re-derives its own policy and forgets about the draft:

• IOURequestStepConfirmation.tsx:187-196 correctly forwards policyDraft into usePolicyForTransaction (the code comment even calls out this exact "Submit to my employer with no existing workspace" case).
• But MoneyRequestConfirmationList.tsx:235 calls usePolicyForTransaction again, this time without policyDraft. In usePolicyForTransaction.ts:50 the result is reportPolicy ?? policyDraft → for a draft workspace reportPolicy (from POLICY) is empty and policyDraft is undefined, so policy is undefined.
• DistanceRequestController.tsx:101 then does getMileageRates(undefined) → {}, so the clear condition customUnitRateID in policyRates at DistanceRequestController.tsx:108 is never true and the error set by setFormError at line 122 sticks.

This is why the rate value still displays correctly (that comes from useDistanceRequestState, which does read POLICY_DRAFTS) yet the "Rate not valid" error stays.

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

Make MoneyRequestConfirmationList resolve the draft policy the same way its parent does. It already has policyID, so subscribe to ${POLICY_DRAFTS}${policyID} and pass that policyDraft into the usePolicyForTransaction call at MoneyRequestConfirmationList.tsx:235. Then policy resolves to the draft workspace, getMileageRates returns the draft's rates, and selecting the default rate clears the error.

Why this is confined to the new flow

Submitting to an existing workspace works because reportPolicy (from the real POLICY collection) is populated, so policy is never undefined. The regression only appears on the 0-workspace employer path introduced by PR #94319, which routes to a freshly created draft workspace. action === SUBMIT also makes isMovingTransactionFromTrackExpense true, so the validation effect runs and sets the error in the first place.

What alternative solutions did you explore? (Optional)

Alternatively, pass the already-resolved policy object down from IOURequestStepConfirmation as a prop instead of re-deriving it inside MoneyRequestConfirmationList, which would avoid the duplicate usePolicyForTransaction call diverging from the parent.

---

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