[Due for payment 2026-04-14] [Due for payment 2026-03-13] [$250] Distance - To field changes from workspace to self DM after changing rate and submitting it

[mitarachim]

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.28-0
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: #81883
Email or phone of affected tester (no customers): isodjnosidjiojiojiso@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:

Precondition:

• Workspace has at least two distance rates.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a manual distance expense.
4. Open the expense.
5. Go offline.
6. Click Rate and select another rate.
7. Go back to self DM.
8. Click Submit it to someone.
9. Select workspace chat.
10. On confirm page, go online.

Expected Result:

To field on confirm page will not change after returning online.

Actual Result:

To field on confirm page changes to self DM.
Amount is flipped.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7092358_1772491789006.3.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022028613855074606911
• Upwork Job ID: 2028613855074606911
• Last Price Increase: 2026-03-02
• Automatic offers:
• FitseTLT | Contributor | 110650049

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[melvin-bot]

Triggered auto assignment to @jliexpensify (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.

[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

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

When a user creates a manual distance expense in self-DM, opens it, goes offline, changes the rate, then initiates "Submit it to someone" and selects a workspace, the "To" field on the confirm page reverts from the selected workspace to self-DM when the user goes back online. The amount also flips sign.

What is the root cause of that problem?

The root cause is in getUpdateTrackExpenseParams (src/libs/actions/IOU/index.ts:5120-5126). When updating a distance rate (customUnitRateID in transactionChanges), the function includes in its successData an Onyx.METHOD.SET that clears TRANSACTION_DRAFT to null:

if (transaction && updatedTransaction && (hasPendingWaypoints || hasModifiedDistanceRate)) {
    successData.push({
        onyxMethod: Onyx.METHOD.SET,
        key: `${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`,
        value: null,
    });

Here's the sequence that causes the bug:

1. Offline: User changes distance rate → updateMoneyRequestDistanceRate queues UpdateMoneyRequestDistanceRate API call, whose successData includes clearing TRANSACTION_DRAFT to null
2. Offline: User starts "Submit it to someone" flow → setMoneyRequestParticipantsFromReport writes workspace participants to the same TRANSACTION_DRAFT key
3. Offline: User reaches confirm page — it reads from TRANSACTION_DRAFT (which has the workspace participant), showing correct "To" field
4. Online: Sequential queue processes UpdateMoneyRequestDistanceRate → server responds → queued successData clears TRANSACTION_DRAFT to null
5. Confirm page's transaction variable (at IOURequestStepConfirmation.tsx:150: optimisticTransaction ?? existingTransaction) now falls back to the real TRANSACTION, which has no workspace participant → "To" field reverts to self-DM

The amount flip happens because getUpdateTrackExpenseParams calculates the amount with isFromExpenseReport: false (line 5099), storing a positive amount. The confirm page now reads this positive amount from the real transaction instead of the draft, and the sign is wrong for a workspace expense report context.

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

In getUpdateTrackExpenseParams at src/libs/actions/IOU/index.ts:5120, change the condition from:

if (transaction && updatedTransaction && (hasPendingWaypoints || hasModifiedDistanceRate))

to:

if (transaction && updatedTransaction && hasPendingWaypoints)

Remove hasModifiedDistanceRate from the condition. The comment at line 5121 already says "Delete the draft transaction when editing waypoints" — the hasModifiedDistanceRate condition was added without considering that the same TRANSACTION_DRAFT key might be used by the "Submit it to someone" flow for storing workspace participants.

The same change should be applied in getUpdateMoneyRequestParams at line 4578 for consistency, since the same pattern exists there.

Distance rate changes don't require the draft to be cleared — the rate/amount updates are written directly to the real TRANSACTION in the optimistic data. The draft clearing was only needed for waypoint edits where the server recalculates distance fields.

What alternative solutions did you explore?

1. Merge instead of SET: Change the Onyx.METHOD.SET to Onyx.METHOD.MERGE with only distance-specific fields cleared. This preserves participants but is fragile — other draft fields could still cause issues.
2. Check for active submit flow: Before clearing the draft, check if TRANSACTION_DRAFT has participants set (indicating a submit flow). This doesn't work because the successData is baked at the time API.write is called (before the submit flow starts), not at the time it's applied.
3. Store participants separately: Move participant storage out of TRANSACTION_DRAFT into a separate Onyx key. This is architecturally cleaner but requires significant refactoring.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.