[Due for payment 2026-05-20] [Due for payment 2026-05-18] Odometer - Added receipt appears then disappears on confirm page

[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.69-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #89774
Email or phone of affected tester (no customers): sjdosjdosjdojnsodj@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 workspace chat.
3. Click + > Track distance > Odometer.
4. Enter start and end reading.
5. Click Save for later.
6. Click + > Track distance > Odometer.
7. Click Next.
8. On confirm page, click Distance.
9. Add odometer start receipt.
10. Click Save.

Expected Result:

The added receipt will show up on confirm page.

Actual Result:

The added receipt appears then disappears on confirm page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148497_1778255601411.9.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jakubkalinski0

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #89774 added code at IOURequestStepDistanceOdometer.tsx:520-527 that calls saveOdometerDraft() whenever odometerDraft is truthy during an edit-from-confirmation save. Since ODOMETER_DRAFT is a global singleton (not scoped to a transaction), it remains truthy from a previous save-for-later request. This triggers an unnecessary draft save → hydration cycle that revokes the blob URLs the confirm page is actively using to display the receipt.

The chain: saveOdometerDraft() async-writes to ONYXKEYS.ODOMETER_DRAFT → useOdometerDraftHydrator detects the new reference → hydrateOdometerDraftIntoTransaction deserializes images into new File objects with new blob URLs and revokes the old blob URLs the confirm page is displaying → receipt disappears.

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

Remove the saveOdometerDraft call from the isEditingConfirmation block (lines 520-527 of IOURequestStepDistanceOdometer.tsx). When editing from the confirmation page, the transaction draft already holds the correct values — syncing them back to the global ODOMETER_DRAFT singleton is unnecessary and harmful. The draft only needs to be kept in sync during the initial create flow, not when returning from a confirmation-page edit.

If the draft sync is needed for a specific save-for-later round-trip scenario, the guard should be tightened to only fire when the draft actually belongs to the current transaction (e.g., by comparing transaction IDs), rather than the current truthy check which matches any draft from any previous request.

What alternative solutions did you explore? (Optional)

An alternative would be to suppress re-hydration in useOdometerDraftHydrator when the user is returning from an edit-from-confirmation (e.g., via a flag or by checking navigation state). However, this is more complex and treats the symptom rather than the cause — the real issue is that saveOdometerDraft shouldn't fire for a draft that doesn't belong to the current transaction.

Supporting evidence

The problematic code (IOURequestStepDistanceOdometer.tsx:516-529):

if (isEditingConfirmation) {
    didSaveEditingConfirmationRef.current = true;
    if (odometerDraft) {  // ← truthy from a DIFFERENT request's save-for-later
        saveOdometerDraft({...}).catch(...);
    }
    Navigation.goBack(confirmationRoute);
    return;
}

The hydration hook (useOdometerDraftHydrator.ts:39): fires whenever the odometerDraft Onyx reference changes, which happens after saveOdometerDraft writes a new object.

Blob URL revocation happens inside hydrateOdometerDraftIntoTransaction → revokeOdometerImageUri, which invalidates the URL the confirm page is currently rendering.

---

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.