Expense-Creating distance manual expense shows unexpected error. #85173

Activity

1. mitarachim

   added this to #expensify-bugson Mar 13, 2026
2. mitarachim

   added

   DeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deployment

   DailyKSv2KSv2

   BugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.

   DeployBlockerIndicates it should block deploying the APIIndicates it should block deploying the API

   on Mar 13, 2026
3. melvin-bot

   assigned

   puneetlath

   on Mar 13, 2026
4. melvin-bot commented on Mar 13, 2026

   

   melvin-botBot

   on Mar 13, 2026 – with Melvin Bot

   More actions

   Triggered auto assignment to @puneetlath (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.
5. melvin-bot commented on Mar 13, 2026

   

   melvin-botBot

   on Mar 13, 2026 – with Melvin Bot

   More actions

   💬 A slack conversation has been started in #expensify-open-source
6. github-actions

   added

   Engineering

   HourlyKSv2KSv2

   and removed

   DailyKSv2KSv2

   on Mar 13, 2026
7. github-actions commented on Mar 13, 2026

   

   github-actionsBot

   on Mar 13, 2026 – with GitHub Actions

   Contributor

   More 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.
8. OSBotify commented on Mar 13, 2026

   

   OSBotify

   on Mar 13, 2026

   Contributor

   More actions

   🔍 Investigation Summary

   Classification: Frontend bug
   Causing PR: #84658 - "Fix manual distance expense from QAB showing amount as zero" by @MelvinBot (High confidence)
   Related Issues: #82801

   Recommendation: ROLL FORWARD

   The fix in PR #84658 addressed a critical issue (manual distance expenses showing $0.00), but appears to have introduced a regression. Reverting would reintroduce the original zero-amount bug, which is also a deploy blocker. A roll-forward fix is needed to address the unexpected error while preserving the amount calculation logic.

   Labels: DeployBlockerCash will be kept (frontend bug blocks App deploy). DeployBlocker will be removed (no backend changes needed).

   📋 Detailed Analysis

   Evidence

   PR #84658 was merged on March 12, 2026 and is included in this staging deploy (v9.3.37-0). The PR modified src/libs/actions/IOU/MoneyRequest.ts to calculate the amount for manual distance expenses when shouldSkipConfirmation is true (QAB flow).

   The new code added:

   const mileageRate = DistanceRequestUtils.getRate({transaction, policy});
   amount = DistanceRequestUtils.getDistanceRequestAmount(distanceInMeters, unit, mileageRate?.rate ?? 0);
   merchant = DistanceRequestUtils.getDistanceMerchant(...);

   Verification

   • ✓ PR Fix manual distance expense from QAB showing amount as zero #84658 modifies src/libs/actions/IOU/MoneyRequest.ts (lines 645-662)
   • ✓ The changes relate to manual distance expense creation
   • ✓ The PR was merged on March 12, aligned with when the staging deploy was cut
   • ✓ Issue is reproducible on staging but NOT on production (confirming it's from a PR in this deploy)

   Root Cause

   The DistanceRequestUtils.getRate() function or one of its dependencies (getMileageRates, getDefaultMileageRate, getPersonalPolicy) may be throwing an error or returning unexpected values in certain scenarios, such as:

   1. Policy not loaded: When creating a distance expense quickly after login, the policy data (including customUnits and distance rates) may not be fully loaded from Onyx yet
   2. Missing distance rates: If the policy doesn't have distance rates configured, getDefaultMileageRate may return undefined, causing issues downstream
   3. Personal policy unavailable: The getPersonalPolicy() function accesses allPolicies which is populated asynchronously via Onyx.connect, potentially returning undefined if called too early

   The original issue #82801 was specifically about the QAB flow with offline creation, but the fix introduced new logic that runs synchronously and may not handle all edge cases gracefully.

   Why Roll Forward Instead of Revert

   • Reverting PR Fix manual distance expense from QAB showing amount as zero #84658 would reintroduce issue [$250] Expense-Creating distance map expense from QAB shows amount as zero #82801 (manual distance expenses showing $0.00), which is also a significant UX bug
   • The core logic of the fix is sound - it just needs better error handling or guards
   • A targeted fix can address both issues without regressing either
9. OSBotify

   removed

   DeployBlockerIndicates it should block deploying the APIIndicates it should block deploying the API

   on Mar 13, 2026
10. MelvinBot commented on Mar 13, 2026

    

    MelvinBot

    on Mar 13, 2026

    Contributor

    More actions

    Proposal

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

    Creating a manual distance expense (from a workspace chat or 1:1 chat) shows an "unexpected error" on staging V9.3.37-0 (Android). The error appears a few seconds after creating the expense, when the user opens it. This does not reproduce in production, indicating it is a regression from a PR in the current staging build.

    What is the root cause of that problem?

    The primary suspect is PR #84658 ("Fix manual distance expense from QAB showing amount as zero"), which modified src/libs/actions/IOU/MoneyRequest.ts:645-662 in the handleMoneyRequestStepDistanceNavigation function's skip-confirmation path.

    What changed: Previously, the skip-confirmation path hardcoded amount: 0 and merchant: translate('iou.fieldPending') for manual distance expenses. PR #84658 replaced this with computed values using DistanceRequestUtils.getRate(), getDistanceRequestAmount(), and getDistanceMerchant() to calculate a real amount and merchant string from the distance and mileage rate.

    How the error surfaces: The error message displayed is iou.error.genericCreateFailureMessage = "Unexpected error submitting this expense. Please try again later." This is set via failureData in buildOnyxDataForMoneyRequest (src/libs/actions/IOU/index.ts:2391-2418), which fires when the backend API (TrackExpense or CreateDistanceRequest) returns an error response. The error shows as a red brick road (RBR) indicator on the transaction preview and as an error message when opening the transaction thread.

    Why it fails: The trackExpense API path (used for TRACK-type expenses in 1:1 chats) now sends a calculated amount instead of 0. Additionally, the merchant value changed from "Pending" to a computed distance merchant string (e.g., "20 mi @ $0.67 / mi"). The backend may be rejecting the request due to the changed parameter values, or there may be an edge case in the DistanceRequestUtils.getRate() call when transaction/policy data isn't fully loaded during the fast skip-confirmation flow.

    A revert PR (#85157) already exists for PR #84658, confirming it has been identified as problematic.

    Note: For the createDistanceRequest path (used for SUBMIT-type expenses in workspace chats), the amount is not sent as an API parameter — the backend calculates it independently. If the error also occurs in workspace chats, there may be a secondary cause from another PR in this staging build, most notably PR #82764 (screen freezing changes that could prevent Onyx updates from reaching frozen screens on Android) or PR #83587 (tax rates v2 merge affecting TransactionUtils and IOU/index.ts).

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

    Immediate fix: Merge the existing revert PR #85157 to revert PR #84658's changes to src/libs/actions/IOU/MoneyRequest.ts. This restores the hardcoded amount: 0 and merchant: 'Pending' values for the skip-confirmation path, matching the pre-regression behavior.

    Follow-up: If the original fix from PR #84658 needs to be re-landed (to address the $0.00 amount issue from #82801), the re-implementation should:

    1. Verify that computed amount/merchant values are accepted by the backend TrackExpense and CreateDistanceRequest endpoints before sending them
    2. Add a guard to fall back to amount: 0 and merchant: 'Pending' if the rate calculation returns undefined/NaN
    3. Test specifically with the skip-confirmation (QAB) flow on Android in both 1:1 chats and workspace chats

    What alternative solutions did you explore? (Optional)

    An alternative would be to keep the amount calculation but only use it for optimistic display, while still sending amount: 0 to the backend (letting the backend recalculate). However, this would only partially fix the original issue (#82801) since the $0.00 display would still appear offline until the backend responds.

    ---

    Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.
11. ahmedGaber93 commented on Mar 13, 2026

    

    ahmedGaber93

    on Mar 13, 2026

    Last edited by ahmedGaber93

    Contributor

    More actions

    @puneetlath I’m still able to reproduce the issue after the revert, so I don’t believe it’s a regression caused by our PR.

    20260313070106822.mp4
12. puneetlath commented on Mar 13, 2026

    

    puneetlath

    on Mar 13, 2026

    Contributor

    More actions

    @MelvinBot the issue can still be seen in the revert PR. Also, the error is happening when creating the expense from within the workspace chat. Any ideas?
13. MelvinBot commented on Mar 13, 2026

    

    MelvinBot

    on Mar 13, 2026

    Contributor

    More actions

    Updated Proposal

    Thanks for the feedback — the fact that the revert of #84658 doesn't fix it and the error occurs in workspace chats (where #84658's code doesn't run) completely rules out #84658 as the root cause. Here's my revised analysis:

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

    Creating a manual distance expense from a workspace chat shows "Unexpected error submitting this expense. Please try again later." after a few seconds. The error persists even with the revert of PR #84658.

    What is the root cause of that problem?

    PR #82672 ("Confirm page shows Amount field with 0.00 amount when receipt is scanning v2") is the root cause.

    This PR added a setMoneyRequestReceiptState function in src/libs/actions/IOU/index.ts that sets receipt: {state: 'OPEN'} on every draft transaction whenever setMoneyRequestAmount, setMoneyRequestCreated, setMoneyRequestDescription, or setMoneyRequestMerchant is called. This contaminates manual distance expense drafts with a spurious receipt object.

    The chain of failure:

    1. User enters distance/amount/merchant in the manual distance flow. Each call to setMoneyRequestAmount / setMoneyRequestMerchant triggers setMoneyRequestReceiptState, adding receipt: {state: 'OPEN'} to the draft transaction.

    2. IOURequestStepConfirmation (line 530-535) reads transaction.receipt and stores it in receiptFiles because item.receipt exists ({state: 'OPEN'}) and isLocalFile is false (no source).

    3. At line 976, the createDistanceRequest call passes receipt: receiptFiles[transaction.transactionID] which is {state: 'OPEN'} instead of undefined.

    4. The CreateDistanceRequest API sends this malformed receipt ({state: 'OPEN'} with no source/filename/type) to the backend, which rejects the request. The failureData fires, displaying the "unexpected error" message.

    This also explains why the error appears in workspace chats specifically — the confirmation page flow (which is always used for workspace chats) picks up the spurious receipt. The skip-confirmation QAB path (affected by #84658) uses a different code path that doesn't go through IOURequestStepConfirmation's receipt handling.

    This same root cause also explains deploy blockers #85152 (split expenses showing "Receipt is missing" error) and #85158 (location modal for manual $0 expenses).

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

    PR #85256 already reverts PR #82672 and was cherry-picked to staging 9.3.37-4. This should fix the issue. The fix should be verified on staging 9.3.37-4+.

    If the original receipt scanning fix from #82672 needs to be re-landed, setMoneyRequestReceiptState should be guarded to only set receipt: {state: 'OPEN'} on transactions that are actual scan requests (e.g., check isScanRequest or transaction.receipt?.source first), rather than all draft transactions unconditionally.

    ---

    Next Steps for Contributor+ team: Please verify that staging 9.3.37-4+ (with PR #85256 deployed) resolves this issue. If so, this can be closed along with #85152 and #85158.
14. m-natarajan commented on Mar 13, 2026

    

    m-natarajan

    on Mar 13, 2026

    More actions

    Passed, Xiaomi Redmi Note 10 / Android 12, App 9.3.37-4

    Screenrecorder-2026-03-13-21-12-48-586.mp4
15. luacmartins commented on Mar 13, 2026

    

    luacmartins

    on Mar 13, 2026

    Contributor

    More actions

    Fixed. Closing.
16. luacmartins

    closed this as completedon Mar 13, 2026
17. luacmartins

    removed

    DeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deployment

    on Mar 13, 2026
18. github-project-automation

    moved this to Done in #expensify-bugson Mar 13, 2026