Expense - Error submitting distance expense after changing report from different workspace

[jponikarchuk]

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.11-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-3951/folder/13176730/56792088/1160416559
Email or phone of affected tester (no customers): sopmdkspomksp@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Create two workspaces - A and B.
• Workspace A is the default workspace.
• For workspace A, disable Submissions, Approvals and Payments in Workflows settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat B.
3. Create an empty report.
4. Open FAB > Track distance > Map.
5. Enter waypoints > Next.
6. On confirm page, click Report.
7. Select the empty report from Step 3.
8. Click Create expense.
9. Open the expense.

Expected Result:

No error will show up.

Actual Result:

Error shows up.

Unexpected error submitting this expense. Please try again later.The selected rate has been deletedUnexpected error creating this chat. Please try again later.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[randomicon00]

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

When a user creates a distance expense using "Track distance" and then changes the target report to one belonging to a different workspace on the confirmation page, the submission fails with the error:

"The selected rate has been deleted"
"Unexpected error submitting this expense. Please try again later."

This happens because the distance rate ID (customUnitRateID) from the original workspace is sent to the server, but that rate doesn't exist in the new workspace's policy.

What is the root cause of that problem?

The root cause is in src/pages/iou/request/step/IOURequestStepReport.tsx in the handleGlobalCreateReport function.

When a user changes the report (and thus the workspace/policy) for a transaction, the code correctly updates:

• The reportID
• The participants
• For Per Diem transactions: the customUnitID and customUnitRateID

However, for Distance requests, the customUnitRateID is NOT updated when the policy changes.

The problematic code only handles Per Diem transactions:

// Clear subrates, and update customUnitID if policy changed for per diem transactions
if (policyChanged && isPerDiemTransaction) {
    setCustomUnitID(transaction.transactionID, newCustomUnitID ?? CONST.CUSTOM_UNITS.FAKE_P2P_ID);
    setCustomUnitRateID(transaction.transactionID, undefined);
    clearSubrates(transaction.transactionID);
}

Distance requests are not handled, so the old rate ID (from Workspace A) remains on the transaction when it's submitted to Workspace B, causing the server to reject it.

Evidence from testing: (I didn't include the whole onyx data but that's what I've got while testing).

• Transaction draft had customUnitRateID: "23048974C6BF8" (belongs to Policy A)
• Transaction was submitted to Policy B (101712EB044BE514)
• Policy B's valid distance rate ID is A623F16F43FD1
• Server rejected because 23048974C6BF8 doesn't exist in Policy B

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

In src/pages/iou/request/step/IOURequestStepReport.tsx:

1. Add import for isDistanceRequest from @libs/TransactionUtils
2. Add import for DistanceRequestUtils from @libs/DistanceRequestUtils
3. Add Onyx subscription for lastSelectedDistanceRates
4. Add distance request handling in handleGlobalCreateReport - when the policy changes and the transaction is a distance request, update the customUnitRateID to a valid rate from the new policy using DistanceRequestUtils.getCustomUnitRateID()

This mirrors the existing logic for Per Diem transactions and ensures that distance requests also get their rate updated when switching workspaces.

What alternative solutions did you explore? (Optional)

We could simply reset the rate to CONST.CUSTOM_UNITS.FAKE_P2P_ID when the policy changes, letting the existing auto-fix logic in MoneyRequestConfirmationList pick up the correct rate. However, this is less direct and relies on downstream components.

The proposed solution is preferred because it directly addresses the issue at the source and follows the existing pattern used for Per Diem transactions.

[melvin-bot]

📣 @randomicon00! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[randomicon00]

Contributor details
Your Expensify account email: mehdi.akiki@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01e9e6c195acf29fe9

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!