[Due for payment 2026-07-13] [$250 - payment 9th July] Distance - Odometer readings are auto cleared after switching tab despite saving for later

[applause-bot]

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.4.25-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: #94899
Email or phone of affected tester (no customers): nsjoijojosdjosjosj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open FAB > Track distance > Odometer.
3. Enter start and end reading > Save for later.
4. Open FAB > Track distance > Odometer.
5. Edit start reading then change back to the previous value.
6. Go to Map tab.
7. Go to Odometer tab.
8. Go to Map tab.

Expected Result:

In Step 7, start and end reading will not be cleared.

Actual Result:

In Step 7, start and end reading are cleared.
In Step 8, Discard changes modal appear because of the cleared fields.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7195341_1782821666594.4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7195341

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c3944c53f333824c6bca8350e018fcb851abb9f6316a1eb028b4ce521df87c75

[melvin-bot]

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

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

Issue Analysis

Root Cause: Deploy blocker from #94899. That PR added an effect that blanks the odometer input state whenever you switch away from the Odometer tab (useOdometerReadingsState.ts:118-133). On returning to the tab, the readings are supposed to be re-hydrated from the transaction by the resync effect (useOdometerReadingsState.ts:179-213) — but that effect only re-runs when the transaction's odometerStart/odometerEnd change (its dep array, line 213). A tab switch doesn't change those values, so the effect never fires and the inputs stay empty → readings appear cleared (Step 7). Switching away again then diffs empty-inputs against the populated baseline, which is a real change, so the "Discard changes?" modal pops up (Step 8).

The underlying transaction is never actually wiped in this flow — only the local input state is, and it's never restored. So the data isn't lost, just hidden, until the spurious discard modal lets the user discard it for real.

Recommended Fix: Two options for the assignee (Julesssss):

1. Revert #94899 — fastest path to unblock the deploy, since this is a freshly-merged feature, not a fix.
2. Fix forward: make the return-to-Odometer path re-hydrate inputs from the (intact) transaction. In the reset effect (useOdometerReadingsState.ts:118-133), when switching back onto the Odometer tab (prevSelectedTab !== DISTANCE_ODOMETER && selectedTab === DISTANCE_ODOMETER), re-seed startReading/endReading/refs and hasInitializedRefs from currentTransaction.comment (mirroring the snapshot logic at lines 153-162) — so re-hydration doesn't depend on the transaction values having changed.

Investigation details

Why the edit-then-revert in Step 5 matters. It's the path that gets past the away-switch without an interrupting modal. getHasUnsavedChanges (IOURequestStepDistanceOdometer.tsx:486-503) returns hasReadingChanges || hasImageChanges, both false after a revert, so the Step 6 switch to Map is silent. Note a related latent bug: userHasUnsavedTypingRef is set true on the first keystroke (line 308) and never reset when the value is reverted (only on submit/discard, lines 358 & 510). It happens not to change the outcome here, but if you fix forward, also reset it on revert in the reading-change handlers to keep the unsaved-changes detection honest.

The transaction is never cleared. The only paths that clear the comment readings are handleTabSwitchDiscard (runs only on a confirmed discard modal) and the blob-failure recovery — neither fires in Steps 5-7. Confirmed via the resync effect dep array and the reset effect being the only local-state mutator on tab-away.

The dep array smell. Line 213 includes userHasUnsavedTypingRef, which is a stable ref object — it can never trigger a re-run, so the resync effect is effectively driven only by odometerStart/odometerEnd/isEditing. None of those change on a tab switch, which is exactly why re-hydration doesn't happen.

Confidence: High on the cleared-readings mechanism (Step 7) — the resync effect provably can't re-fire on tab return when transaction readings are unchanged, and the tab screen stays mounted. Medium-high on the spurious-modal mechanism (Step 8), which follows directly from the inputs being wrongly emptied.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94961) to create a draft PR (fix-forward option 2).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.