[HOLD for #72230] IOU - Unexpected errors when submitting track expense (manual/map) to workspace

[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.2.94-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #78253
Email or phone of affected tester (no customers): fhdfye@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/Chrome, iPhone 16/iOS 18.7.1
App Component: Money Requests

Action Performed:

Precondition: Account has Self DM & new workspace

1. Navigate to staging.new.expensify.com
2. Go to Self DM
3. Create a track expense either manual or map expense
4. Select Submit to someone
5. Submit the expense to workspace
6. Observe unexpected error appears in Workspace chat
7. Go to Self DM & observe error deleting this expense displayed

Expected Result:

User able to submit manual & map track expenses from Self DM to workspace without any errors

Actual Result:

Unexpected errors when submitting track expense (manual/map) to workspace

1. "Unexpected error submitting this expense. Please try again later. Unexpected error deleting this expense. Please try again later. The selected rate has been deleted" error appears in workspace chat
2. "Unexpected error deleting this expense. Please try again later." error appears in Self DM

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7042237_1767714361390.405.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

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

When submitting a track expense (manual or map distance) from Self DM to a workspace, unexpected errors appear:

• "Unexpected error submitting this expense"
• "Unexpected error deleting this expense"
• "The selected rate has been deleted"

What is the root cause of that problem?

When a distance track expense is created in Self DM, it uses CONST.CUSTOM_UNITS.FAKE_P2P_ID as the customUnitRateID (see src/libs/DistanceRequestUtils.ts:299-307):

function getCustomUnitRateID({...}): string {
    let customUnitRateID: string = CONST.CUSTOM_UNITS.FAKE_P2P_ID;

    if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
        return customUnitRateID;  // Returns FAKE_P2P_ID for self DM
    }
    // ...
}

When convertBulkTrackedExpensesToIOU submits the expense to a workspace:

1. It calls getMoneyRequestInformation which builds an optimistic transaction
2. buildOptimisticTransaction in TransactionUtils/index.ts:387-391 sets distanceUnit and quantity for distance transactions but NOT customUnitRateID:

   if (isMapDistanceTransaction || isManualDistanceTransaction) {
       lodashSet(commentJSON, 'customUnit.distanceUnit', ...);
       lodashSet(commentJSON, 'customUnit.quantity', distance);
       // Missing: customUnitRateID is not set!
   }

3. Then in getMoneyRequestInformation line 3708, the existing transaction is merged:

   if (isDistanceRequest && existingTransaction) {
       optimisticTransaction = fastMerge(existingTransaction, optimisticTransaction, false);
   }

4. This preserves the original FAKE_P2P_ID from the Self DM track expense
5. Backend receives FAKE_P2P_ID which is not a valid rate for the workspace, causing "The selected rate has been deleted" error

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

In src/libs/TransactionUtils/index.ts, update buildOptimisticTransaction to also set customUnitRateID when building a distance transaction for a policy:

if (isMapDistanceTransaction || isManualDistanceTransaction) {
    // Set the distance unit, which comes from the policy distance unit or the P2P rate data
    lodashSet(commentJSON, 'customUnit.distanceUnit', DistanceRequestUtils.getUpdatedDistanceUnit({transaction: existingTransaction, policy}));
    lodashSet(commentJSON, 'customUnit.quantity', distance);
+
+   // Set the rate ID - use policy's default rate if submitting to a workspace
+   if (policy?.id) {
+       const defaultMileageRate = DistanceRequestUtils.getDefaultMileageRate(policy);
+       if (defaultMileageRate?.customUnitRateID) {
+           lodashSet(commentJSON, 'customUnit.customUnitRateID', defaultMileageRate.customUnitRateID);
+       }
+   }
}

This ensures that when a track expense is converted to a workspace expense, it gets a valid customUnitRateID from the target workspace's default mileage rate instead of preserving the invalid FAKE_P2P_ID.

What alternative solutions did you explore?

N/A

[parasharrajat]

we are working on distance rates here #72230 so this issue might be solved.

[CortneyOfstad]

We'll put this issue on hold 👍

[CortneyOfstad]

On-hold issue is still moving with most recent comment here