Distance - Rate field shows error when Submissions are off and To field is workspace chat

[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.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: #96228
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.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:

• Create a workspace and disable Submissions in Workflows settings.

1. Go to staging.new.expensify.com
2. Open FAB > Track distance > Manual.
3. Enter amount > Next.
4. On confirm page, click To field.
5. Select workspace chat.
6. Click Rate field.

Expected Result:

Rate field should be clickable after changing participant to workspace chat.

Actual Result:

Rate field is not clickable after changing participant to workspace chat.
It shows pending with error "Rate not valid".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213096_1784599871510.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7213096

[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/237f9e2e2d8167a4ba1cde2b4f679f794981333c35c02e735e7acba92c8db77e

[melvin-bot]

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

[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

Problem

On a distance expense, switching the To participant to a workspace chat on the confirmation page leaves the Rate field stuck with a Rate not valid error and non‑clickable. This is a deploy blocker regressed by #96228 (removed the isNewManualExpenseFlowEnabled beta), which made the embedded confirmation‑page participant picker the default flow.

Root Cause

When you pick a new participant, handleParticipantsAdded in IOURequestStepConfirmation.tsx:371-401 only re‑selects the distance rate in the P2P branch (if (!isPolicyExpenseChatParticipant)). When the new participant is a workspace chat, setCustomUnitRateID is never called, so the transaction keeps its P2P rate ID (FAKE_P2P_ID).

Then DistanceRequestController.tsx:92-137 runs against the workspace: FAKE_P2P_ID isn't in the workspace's rates and no matching rate exists, so it calls setFormError('iou.error.invalidRate'). The auto‑select fallback that would normally rescue this (DistanceRequestController.tsx:180-216) returns early when there's no default/last‑selected workspace rate — which is why Submissions/Workflows off matters: such a workspace has no enabled default distance rate. With no valid rate resolved, RateField sets isRateInteractive = false, so the field is non‑clickable.

The old participants‑step path did this correctly — useParticipantSubmission.ts:258-284 selects the workspace rate for a policy‑expense‑chat. The new embedded handler dropped that behavior for workspace chats.

Recommended Fix

Add a workspace‑chat branch to handleParticipantsAdded that assigns the workspace distance rate, mirroring useParticipantSubmission:

if (isDistanceRequest) {
    const rateID = DistanceRequestUtils.getCustomUnitRateID({
        reportID: participantReportID,
        isPolicyExpenseChat: true,
        policy,
        lastSelectedDistanceRates,
        expenseDate: transaction?.created,
    });
    setCustomUnitRateID(activeTransactionID, rateID, transaction, policy, false, policy?.outputCurrency);
}

Given this is a deploy blocker, reverting #96228 is the fastest safe option if a forward‑fix can't be verified quickly.

Repro & confidence

Repro: FAB > Track distance > Manual > enter amount > Next > confirm page > To > select workspace chat > click Rate. (Workspace must have Submissions disabled in Workflows.)

Confidence: High — deterministic front‑end state bug, code path confirmed end‑to‑end. One config detail to confirm in the fix: whether a Workflows‑off workspace can still have an enabled default distance rate; the fix above assigns the workspace rate regardless, which is correct in both cases.

---

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

[trjExpensify]

I can reproduce it, but to confirm:

• With autoReporting disabled ("Submissions" disabled) on the default workspace, the rate used when creating the expense is still the default workspace's default rate. That's consistent with the coding (i.e category list etc) you see when creating an unreported expense.
• So when you change the participant to the default workspace to not create it unreported, there shouldn't be a rate change in the mix. It's already created using the default rate from your default workspace.

This is also how it works from the selfDM > move to the default workspace flow works (see how there aren't any errors):

2026-07-21_10-23-27.mp4