IOU - Distance reverts to original distance after editing it and submitting the expense from self DM

[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.3.73-4
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: #89858
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@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:

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a distance expense.
4. Open the expense.
5. Click Distance.
6. Go to Manual tab.
7. Edit the distance and save it.
8. Click on the header > Submit it to someone.
9. Select workspace chat.
10. On confirm page, click Rate field.
11. Select any rate.
12. Click Create expense.
13. Open the created expense in workspace chat.
14. Click Distance.

Expected Result:

Distance will not revert to the original distance after editing it and submitting the expense from self DM.

Actual Result:

Distance reverts to the original distance after editing it and submitting the expense from 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

Bug7153152_1778689461675.12.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #89858 - "fixed manual distance tab blockers" by @mukhrr (High confidence)
Related Issues: #83781

Recommendation: REVERT

PR #89858 introduced a change to useExpenseSubmission.ts intended to preserve manually-edited distances when submitting a map-based expense from self DM. However, the regression tests linked in the PR body (#89847) describe the exact same scenario as this deploy blocker — distance should persist after submitting from self DM — which means the fix did not work as expected and the bug is still present despite the PR being merged.

Assigned: @mukhrr (PR author), @aimane-chnaif and @youssef-lr (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR is the cause). No label changes made.

Detailed Analysis

Evidence

• The issue body explicitly references PR fixed manual distance tab blockers #89858 as the test source (https://github.com/Expensify/App/pull/89858) and melvin-bot confirmed this assignment.
• The bug scenario — edit distance on Manual tab in self DM, submit to workspace, distance reverts — matches regression test [Due for payment 2026-05-18] [Due for payment 2026-05-15] Distance - Edited distance reverts to default distance after submitting distance from self DM #89847 that the PR itself was supposed to fix, meaning the fix is incomplete or introduced a new regression.
• The PR modifies src/pages/iou/request/step/confirmation/useExpenseSubmission.ts lines 313-326: it changed the distance field check from isManualDistanceRequest to isDistanceRequestTransactionUtils(item) to also cover map-based expenses. The intent was that convertTrackedExpenseToRequest on the backend receives the user's edited quantity. If the quantity is not correctly stored in item.comment.customUnit.quantity for the draft/optimistic transaction at submission time, the distance is dropped.
• The issue is reproducible on staging only (not production), which is consistent with this being a new-feature regression introduced by a staging-only PR.

Verification

• Affected files in the bug: src/pages/iou/request/step/confirmation/useExpenseSubmission.ts, src/libs/actions/IOU/UpdateMoneyRequest.ts, src/libs/TransactionUtils/index.ts
• PR fixed manual distance tab blockers #89858 modifies all of these files — confirmed via gh pr view 89858 --json files.
• The PR merge date is 2026-05-07, which aligns with when this staging version (9.3.73-4) would have picked it up.

Root Cause

When a distance expense is created in self DM using the Manual tab, the user edits comment.customUnit.quantity directly. When "Submit it to someone" is triggered, useExpenseSubmission iterates over items and passes a distance parameter to convertTrackedExpenseToRequest. PR #89858 broadened the check from isManualDistanceRequest to any isDistanceRequest to cover this path. However, in the "submit from self DM" flow, the item being iterated may be a draft/optimistic transaction whose comment.customUnit.quantity is not yet populated with the edited value (or has been reset by the waypoints branch in getUpdatedTransaction), causing the backend to fall back to recomputing distance from waypoints and discarding the manual edit.