Android - Odometer - Receipt is not visible after relaunching app and it loads infinitely

[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.67-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: #87726
Email or phone of affected tester (no customers): josdjnosdjionjsdonjisod@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Open FAB > Track distance > Odometer.
3. Enter start and end reading.
4. Add a receipt to start reading.
5. Tap Save for later.
6. Kill and relaunch the app.
7. Open FAB > Track distance > Odometer.
8. Tap on the receipt added from Step 4.

Expected Result:

Receipt will be visible after relaunching app.

Actual Result:

Receipt is not visible after relaunching app and it loads infinitely.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7145317_1778009534012.az_recorder_20260506_032937_1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #87726 - "Add Save for later to Odometer screen" by @jakubkalinski0 (High confidence)
Related Issues: None

Recommendation: REVERT

PR #87726 introduced a new "Save for later" feature for the Odometer screen that is directly reproducing this bug. The feature does not exist in production, reverting the PR removes the broken behavior entirely without risk of a production regression.

Assigned: @jakubkalinski0 (PR author), @Julesssss, @DylanDylann (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR caused the issue). DeployBlocker removed — no backend change is needed.

Detailed Analysis

Evidence

• The issue body explicitly links PR [Odometer] Add save for later functionality #87726 as the regression source (the If this was caught during regression testing field references that PR URL).
• The melvin-bot comment on the issue confirms: "You have been assigned to this deploy blocker because you recently merged this PR: [Odometer] Add save for later functionality #87726".
• The bug reproduces the exact new flow introduced by PR [Odometer] Add save for later functionality #87726: FAB > Track distance > Odometer > add receipt > Save for later > kill & relaunch > open Odometer > tap receipt = infinite load.
• PR [Odometer] Add save for later functionality #87726 is listed in the current StagingDeployCash (Deploy Checklist: New Expensify 2026-05-05 #89627) and the issue is marked staging-only ("Reproducible in production? N/A - new feature").

Verification

• Affected files from the PR that relate to the bug:
  • src/libs/actions/OdometerTransactionUtils.ts — introduces saveOdometerDraft, hydrateOdometerDraftIntoTransaction, deserializeOdometerDraftImage, and serializeOdometerDraftImage.
  • src/hooks/useOdometerDraftHydrator.ts — new hook responsible for re-hydrating persisted draft images back into the transaction on mount.
  • src/hooks/useRestartOnOdometerImagesFailure/index.ts — significantly modified to co-operate with the new draft; now waits for odometerDraftStatus to resolve before proceeding.
  • src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx — wires the "Save for later" button and integrates useOdometerDraftHydrator.
  • src/ONYXKEYS.ts — adds the new ODOMETER_DRAFT Onyx key.
• The PR modifies all files in the distance-odometer request flow that handle receipt images and draft persistence.

Root Cause

On Android (native), the PR stores image file URIs directly in the persisted ODOMETER_DRAFT Onyx key (the code path getPlatform() !== CONST.PLATFORM.WEB returns the URI as-is rather than converting to base64). After the app is killed and relaunched, the draft URI is rehydrated into the transaction via hydrateOdometerDraftIntoTransaction. However, when the user taps the receipt thumbnail, the image viewer attempts to load from that URI. The useRestartOnOdometerImagesFailure hook guards on hasVerifiedBlobs, and the blob-check path for native file URIs (not blob: prefixed) may never mark asyncVerificationPassed as true — specifically the updated code now filters urlsToCheck only to entries with blob: prefixed paths, meaning an empty array flows through Promise.all immediately, yet the component may still render a stuck loading indicator because the receipt source URI from the draft is a stale Android content URI that is no longer resolvable after a full app restart. The infinite loading is the fallback UI when the image cannot be fetched.