[$250] Re-entered odometer readings/image do not persist after refreshing the page

[jponikarchuk]

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.74-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-28774/folder/18717689/106413858/1413061849
Email or phone of affected tester (no customers): kiatest.80+ck513262@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/Chrome, Pixel 8a/Android 16
App Component: Money Requests

Action Performed:

Preconditions

1. User is logged in to NewDot
2. User is a Admin/member of at least one workspace

Steps:
1/ Navigate to staging.new.expensify.com or launch Hybrid app
2. Click the + global create button >> Track Distance >> Odometer option
3. Enter start and end readings
4. Click the image button and take a start odometer photo
5. Click Save for later and verify that the page closes
6. Reopen the Distance Request page and navigate to the Odometer tab
7. Verify that the reading and image data entered previously are displayed correctly
8. Clear the readings & delete image so they are empty and click Save for later
9. Reopen the Odometer page and verify that no reading data is displayed
10. Re-enter start and end readings and take a start odometer photo
11. Kill the app (Mobile) or close/refresh the site tab (Web)
12. Reopen the app/tab and navigate back to the Odometer page

Expected Result:

Re-entered odometer readings and image data are still displayed correctly (data persistence) after refreshing page or killing/reopening app

Actual Result:

Re-entered odometer readings/image do not persist after refreshing or killing/reopening the page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054944259160623871
• Upwork Job ID: 2054944259160623871
• Last Price Increase: 2026-05-14

[MelvinBot]

Proposal

What is the root cause of that problem?

The odometer form has a two-tier persistence model with a gap:

1. Readings (start/end) are stored only in React local state (useState) during typing — they are never auto-persisted to Onyx. They only get written to the transaction draft when the user explicitly presses "Save for later" or "Next" (IOURequestStepDistanceOdometer.tsx:340-348).

2. Images are stored in the transaction draft as ephemeral blob: URLs (web) or temp file URIs (native) via setMoneyRequestOdometerImage. These don't survive page refresh.

3. The only durable persistence is the ODOMETER_DRAFT Onyx key, which serializes images to base64 and stores readings — but it's only written when saveOdometerDraft is called via the "Save for later" button (handleSaveForLater).

In the repro, after clearing data and saving (step 8), clearOdometerDraft sets ODOMETER_DRAFT to null. When the user re-enters data (step 10) without pressing "Save for later" again, ODOMETER_DRAFT remains null. On refresh/kill, React state is lost, blob URLs become invalid, and useRestartOnOdometerImagesFailure finds no draft to rehydrate from — so it wipes everything via clearOdometerDraftTransactionState.

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

Auto-save odometer data to ODOMETER_DRAFT as the user enters it, rather than only on explicit "Save for later":

1. In IOURequestStepDistanceOdometer.tsx, add a debounced effect that calls saveOdometerDraft whenever readings or images change (e.g., debounce ~500ms on reading changes, immediate on image capture).
2. In IOURequestStepOdometerImage, after setMoneyRequestOdometerImage is called, also trigger a saveOdometerDraft to serialize the image to base64 immediately.

This ensures ODOMETER_DRAFT is always up-to-date and the hydrator can restore data after any refresh/kill.

What alternative solutions did you explore? (Optional)

• Warn users about unsaved data: Add a discard-changes confirmation on refresh — this doesn't fix the core persistence expectation and is a poor UX.
• Persist blob URLs via Service Worker caching: Overly complex and fragile; base64 serialization via the existing saveOdometerDraft mechanism is already built and proven.

Related issues

• Expensify/App#89633 — Edited start reading not reflected on Odometer tab after returning from confirmation page (related odometer state issue)
• Expensify/App#88975 — Receipt disappears on confirm page after refresh (similar persistence gap for receipts)

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @rojiphil (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022054944259160623871

[neerajbachani]

h

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

There is only one refresh-durable store for odometer data — the ODOMETER_DRAFT Onyx key — and it is written exclusively by the "Save for later" button. Anything entered without tapping "Save for later" is not stored durably:

• Readings typed into the inputs live only in React component state (startReading/endReading useState in useOdometerReadingsState.ts#L83-L84). They are written to Onyx only when the user taps Next (setMoneyRequestOdometerReading in IOURequestStepDistanceOdometer.tsx#L341) or Save for later (saveOdometerDraft). The keystroke handlers (#L292-L316) only call setStartReading/setEndReading.
• The image captured at step 10 is written to the transaction draft immediately, but only as a blob: URL. Blob URLs do not survive a page reload.

The repro's step 10 ("re-enter readings and take a photo") is followed directly by killing the app — with no "Save for later". So on reload:

1. The typed readings are gone — they were never persisted anywhere.
2. The transaction draft still holds the image, but as a now-dead blob: URL. useRestartOnOdometerImagesFailure detects the unreadable blob and, because there is no ODOMETER_DRAFT to rehydrate from, takes the else branch and calls clearOdometerDraftTransactionState(transaction) — which actively wipes the odometer readings/images off the transaction draft — then navigates back to the start of the flow. See useRestartOnOdometerImagesFailure/index.ts#L105-L113 and OdometerTransactionUtils.ts#L89-L98.

This also explains the asymmetry in the bug report: the first entry (steps 3-5) survives a reload because step 5 tapped "Save for later", which serialized the image to base64 inside the persisted ODOMETER_DRAFT (saveOdometerDraft #L149-L166). After reload, useRestartOnOdometerImagesFailure sees the dead blob but finds a truthy odometerDraft, so it re-mints fresh blobs via hydrateOdometerDraftIntoTransaction (#L105-L107) instead of wiping. The re-entry (step 10) never created an ODOMETER_DRAFT, so it falls into the wipe path.

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

Make the live-edit path durable instead of relying on the user remembering to tap "Save for later". Odometer readings and images should be persisted to ODOMETER_DRAFT (the only refresh-survivable store, with base64 image serialization) as they are entered — reusing the exact mechanism "Save for later" already uses.

Persist readings on change rather than leaving them in component state:

 const handleStartReadingChange = (text: string) => {
     if (!isOdometerInputValid(text, startReading)) {
         return;
     }
     const textForDisplay = DistanceRequestUtils.prepareTextForDisplay(text);
     setStartReading(textForDisplay);
     startReadingRef.current = textForDisplay;
     userHasUnsavedTypingRef.current = true;
+    // Persist to the refresh-durable ODOMETER_DRAFT so a reload/app-kill doesn't drop unsaved readings.
+    persistOdometerDraftFromCurrentInputs();
     if (formError) {
         setFormError('');
     }
 };

persistOdometerDraftFromCurrentInputs would be a small (debounced) helper that calls saveOdometerDraft({startReading, endReading, startImage: odometerStartImage, endImage: odometerEndImage}) with the current values — the same call handleSaveForLater already makes. The end-reading handler gets the same treatment.

For images, the capture path (useOdometerImageHandlers → setMoneyRequestOdometerImage) should likewise write the image into ODOMETER_DRAFT (base64) at capture time, not only on "Save for later", so useRestartOnOdometerImagesFailure finds a draft to rehydrate from after a reload instead of hitting the wipe branch.

With odometer data continuously mirrored into ODOMETER_DRAFT, the existing useOdometerDraftHydrator + useRestartOnOdometerImagesFailure rehydration path covers the kill/refresh case for re-entered data exactly as it already does for the "Save for later" case.

What alternative solutions did you explore? (Optional)

• Only fixing the recovery branch in useRestartOnOdometerImagesFailure (don't wipe when there's no draft). Rejected — the blob URL really is dead and unrenderable, and the readings were never persisted at all, so there is genuinely nothing to recover; not wiping would just leave a broken image reference.
• Persisting readings into TRANSACTION_DRAFT.comment on change instead of ODOMETER_DRAFT. This would cover readings, but images in the transaction draft are still blob: URLs that die on reload — ODOMETER_DRAFT's base64 serialization is what actually makes the data refresh-durable, so readings and images should both go there for consistency.

[aswin-s]

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

When a user creates a Distance Request with odometer readings and a start photo, saves it for later (step 5), then reopens the page and navigates to the Odometer tab (step 6), the previously entered readings and image data do not persist—the Odometer tab displays as empty. The expected behavior is that the draft data persists across page refreshes and app restarts. This occurs on both NewDot web and the Hybrid app.

What is the root cause of that problem?

The bug originates in src/hooks/useOdometerDraftHydrator.ts in the useOdometerDraftHydrator function (lines 19–53). The issue involves two module-level cache variables—lastHydratedDraft and lastHydratedTransactionID—that need to be managed together. After the user saves for later and the page is refreshed (or the app is killed and relaunched), Onyx rehydrates the draft as a new JavaScript object. However, if the same lastHydratedDraft reference was previously assigned during an earlier render cycle (HMR, SPA navigation, or prior session), the hydration effect short-circuits on line 33 (if (lastHydratedDraft === odometerDraft) { return; }), and the hydration step never executes. This leaves the transaction comment unpopulated, so the Odometer tab's local state remains empty when initialized from transaction.comment (see working analog in src/hooks/useRestartOnOdometerImagesFailure/index.ts).

Additionally, the effect dependency array (line 52) does not include transaction?.transactionID, so when initMoneyRequest creates a new transaction with a different ID after a tab reset, the effect does not re-fire to hydrate into the newly created transaction. The closure returned on line 54 also captures a stale transaction reference, causing transaction?.transactionID to resolve incorrectly on hard refresh.

Because lastHydratedDraft is module-level (shared across all hook instances and persists across SPA navigations), a second scenario also triggers the bug: the user clears readings and saves for later (step 8), which writes an empty draft to Onyx. On the next mount, lastHydratedDraft still points to that empty draft object. When the user re-enters readings and saves for later (step 10), Onyx writes a new draft object—but on refresh, Onyx restores the draft as a fresh object with the same shape. If the module cache was not reset, the identity guard fires on both lastHydratedDraft and lastHydratedTransactionID, skipping hydration entirely. Both caches must be invalidated together whenever the transaction changes or when the hook mounts with a new transaction ID.

On web, Onyx restoration happens synchronously during the SPA re-render; on mobile, the native SQLite persistence layer restores Onyx asynchronously after the JS bridge initializes. This means the hydration effect may fire before odometerDraft is populated on mobile, making the transaction?.transactionID dependency critical to ensure a second effect run occurs once both the transaction and draft are available.

App/src/hooks/useOdometerDraftHydrator.ts

Lines 19 to 53 in 2273f92

	let lastHydratedDraft: OdometerDraft | null = null;
	function useOdometerDraftHydrator({
	transaction,
	transactionRequestType,
	isLoadingTransaction = false,
	isLoadingSelectedTab = false,
	}: UseOdometerDraftHydratorParams): (newIOUType: IOURequestType) => void {
	const [odometerDraft] = useOnyx(ONYXKEYS.ODOMETER_DRAFT);
	useEffect(() => {
	if (transactionRequestType !== CONST.IOU.REQUEST_TYPE.DISTANCE_ODOMETER) {
	return;
	}
	if (!odometerDraft) {
	return;
	}
	if (isLoadingTransaction || isLoadingSelectedTab) {
	return;
	}
	if (lastHydratedDraft === odometerDraft) {
	return;
	}
	// Skip when the comment already reflects the draft. saveOdometerDraft writes from the
	// edit-from-confirmation flow otherwise mint fresh blob URLs via the serialize/deserialize
	// round-trip and revoke the URLs the confirm page is currently displaying.
	if (!isOdometerDraftPendingHydration(odometerDraft, transaction?.comment)) {
	lastHydratedDraft = odometerDraft;
	return;
	}
	hydrateOdometerDraftIntoTransaction(transaction?.transactionID ?? CONST.IOU.OPTIMISTIC_TRANSACTION_ID, odometerDraft, transaction?.comment);
	lastHydratedDraft = odometerDraft;
	// transaction.comment intentionally excluded — it changes after our own merge and would re-fire.
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [transactionRequestType, odometerDraft, isLoadingTransaction, isLoadingSelectedTab]);

https://github.com/Expensify/App/blob/2273f92fc7d051fefd20c5ae38517c88f08816be/src/hooks/useRestartOnOdometerImagesFailure/index.ts

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

1. File: src/hooks/useOdometerDraftHydrator.ts
   Function: useOdometerDraftHydrator
   Changes:

   • Add a second module-level cache variable lastHydratedTransactionID (initialized to null) alongside lastHydratedDraft. Both caches must be checked and reset together so that a transaction switch always triggers re-hydration, even when the draft object reference or shape is unchanged.

   • Capture the live transactionID inside the effect using an early null-guard: if transaction is null, undefined, or lacks a transactionID, exit the effect immediately without updating either cache. This prevents runtime errors during initial load, logout, or race conditions where the transaction has not yet been created by initMoneyRequest.

   • Update the identity guard to short-circuit only when both caches match:

     const liveTransactionID = transaction?.transactionID;
     if (!liveTransactionID) {
       return;
     }
     if (lastHydratedDraft === odometerDraft && lastHydratedTransactionID === liveTransactionID) {
       return;
     }

     This ensures that when the transaction ID changes (e.g., after initMoneyRequest creates a new transaction), hydration proceeds even if the draft object reference happens to be the same.

   • Use a useRef to hold the latest transaction snapshot so the cleanup closure (line 54) reads the live transactionID rather than a stale closure-captured value. This is the same pattern used by useRestartOnOdometerImagesFailure to avoid stale closures.

   • Reset both lastHydratedDraft and lastHydratedTransactionID to null at the top of the effect when the live transactionID differs from lastHydratedTransactionID. This ensures the module-level cache is scoped per-transaction, not globally across all navigations or sessions.

   • Add transaction?.transactionID to the useEffect dependency array (line 52). On mobile, where Onyx restores asynchronously, the effect will re-run once the transaction ID is established, guaranteeing hydration even when the draft arrives after the first render.

   Blast radius: This fix is localized to useOdometerDraftHydrator and its two callers in src/hooks/useResetIOUType.ts (lines 71 and 109). No other files reference this hook, and the change maintains the existing API signature—only internal caching and effect triggering are modified. The returned closure's behavior is unchanged from the caller's perspective.

What alternative solutions did you explore? (Optional)

1. Seed local state directly from odometerDraft in useOdometerReadingsState when transaction.comment is empty.
   Rejected: This masks the underlying hydration miss and creates two sources of truth (Onyx ODOMETER_DRAFT vs transaction.comment). The hydration utility was designed as the single funnel for converting the draft into transaction state; bypassing it leaves blob URL revocation, base64 round-trip, and the edit-from-confirmation sync path inconsistent.

[aswin-s]

Updated the proposal above to tighten 4 edge cases (additional guards and broader coverage).

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

Two separate gaps, one per data type, both stemming from the same thing: in the create flow nothing durable is written to Onyx until the user explicitly taps Next or Save for later.

1. Readings are never persisted to Onyx during entry.
startReading / endReading live only in React local state inside useOdometerReadingsState. They reach Onyx only via setMoneyRequestOdometerReading in navigateToNextPage (Next) or saveOdometerDraft in handleSaveForLater. On reopen, the init effect seeds the inputs only from currentTransaction.comment.odometerStart/End — values that were never written. So a kill/refresh before Next/Save loses the readings on every platform.

2. The image is persisted only as a volatile blob: URL.
The captured image is written to TRANSACTION_DRAFT.comment by setMoneyRequestOdometerImage, but on web that value is a blob: URL, which is dead after a page refresh. The only durable copy is the base64 that saveOdometerDraft serializes into ODOMETER_DRAFT — and that runs only on Save for later. On reopen, useRestartOnOdometerImagesFailure detects the dead blob: URL; because ODOMETER_DRAFT is empty (round 2 never tapped Save for later) it takes the else branch → clearOdometerDraftTransactionState(transaction) wipes the comment and restarts the flow.

Round 1 works only because step 5's "Save for later" populated ODOMETER_DRAFT. Round 2 skips it, so the hydrator/recovery hooks have nothing to restore.

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

1. Persist readings to the transaction draft as they are typed.
In handleStartReadingChange / handleEndReadingChange, after updating local state, also write to the storage-backed TRANSACTION_DRAFT — the same call navigateToNextPage already makes. TRANSACTION_DRAFT is persisted and scoped to the transaction, so the readings survive an app kill on all platforms and are still cleaned up with the transaction-draft lifecycle (no global state leak). On reopen the existing init effect re-seeds the inputs from comment.odometerStart/End.

 const handleStartReadingChange = (text: string) => {
     if (!isOdometerInputValid(text, startReading)) {
         return;
     }
     const textForDisplay = DistanceRequestUtils.prepareTextForDisplay(text);
     setStartReading(textForDisplay);
     startReadingRef.current = textForDisplay;
     userHasUnsavedTypingRef.current = true;
+    // Persist in-progress readings so they survive an app kill / page refresh before "Next".
+    if (isCreatingNewRequest) {
+        const start = parseFloat(DistanceRequestUtils.normalizeOdometerText(textForDisplay, fromLocaleDigit));
+        const end = parseFloat(DistanceRequestUtils.normalizeOdometerText(endReading, fromLocaleDigit));
+        setMoneyRequestOdometerReading(transactionID, Number.isNaN(start) ? null : start, Number.isNaN(end) ? null : end, isTransactionDraft);
+    }
     if (formError) {
         setFormError('');
     }
 };

…and the symmetric change in handleEndReadingChange.

2. Make the captured image durable in the create flow.
The image write currently stores a volatile blob: URL on web. In the create flow, run the captured image through convertFileObjectOrUriToBase64DataURL (already used by serializeOdometerDraftImage) and store the resulting data URL in comment.odometerStartImage / odometerEndImage instead of a blob: URL. A data URL survives a refresh, getImageSource / ReceiptImage already render string sources directly, and useRestartOnOdometerImagesFailure's startsWith('blob:') check no longer mis-fires — so the image stays put without needing the ODOMETER_DRAFT round-trip.

What alternative solutions did you explore?

Auto-call saveOdometerDraft (writing to ODOMETER_DRAFT) on every readings/image change in the create flow, reusing the proven round-1 hydration path. Rejected as the primary fix: ODOMETER_DRAFT is a single global key dedicated to the explicit "Save for later" intent. Auto-populating it means a flow abandoned via the back button leaves a stale global draft that useOdometerDraftHydrator would later rehydrate into the next fresh odometer request. Scoping persistence to TRANSACTION_DRAFT (change #1) avoids that because it is tied to the transaction's own lifecycle.