[Exploratory] GPS - Resume offline does not update current location after reconnecting

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.62-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: #99391
Email or phone of affected tester (no customers): applausetester+h07@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: samsung a31 android 12
App Component: Other

Action Performed:

Precondition:
A GPS distance expense is actively tracking and already has some distance recorded.

Steps to Reproduce:

1. Tap Stop to pause GPS tracking.
2. Turn off the internet connection.
3. Tap Resume to continue GPS tracking.
4. Walk a few meters while the device is offline.
5. Turn the internet connection back on.
6. Observe the current location displayed on the map

Expected Result:

The map automatically updates and displays the user's current location after the internet connection is restored.

Actual Result:

After resuming the GPS tracking while offline and restoring the internet connection, the map does not automatically update to the user's current location. The GPS position remains displaced from the user's actual location.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7243784_1787790756437.WhatsApp_Video_2026-08-26_at_20.07.18.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @GCyganek

[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/fef0787423f63eab895445a687b2171d9995946a3ef087318c7cd691fe1c1857

[MelvinBot]

Proposal

What is the root cause of that problem?

Going offline unmounts the entire Mapbox map, but GPSMapView itself stays mounted — so its stale location state survives the outage and is reused when the map comes back. Nothing on reconnect asks the device where it is now.

Three things combine:

1. The map is torn down, its parent is not. GPSMapView.tsx:194 swaps the whole Mapbox.MapView subtree for PendingMapView when isOffline is true. That kills Mapbox.UserLocation, so no onUpdate fires. But GPSMapView is rendered unconditionally by its parent, so lastLocation (:94) keeps its pre-offline value. On reconnect a brand-new native map is built and GPSDirection.tsx:23-28 immediately draws the route head at that old coordinate — literally "displaced from the user's actual location".

2. No reconnect re-centering exists. The only reconnect handler in this feature, useUpdateGpsTripOnReconnect.ts, just reverse-geocodes waypoint addresses. Unlike the regular MapView.tsx:106-127, GPSMapView never calls getCurrentPosition() at all.

3. Two latches block the camera from recovering. shouldUseImmediateFollowTransition (:93) is already false by then, so the rebuilt camera does a slow default transition with no initial bounds to fall back on (rnmapbox nulls out bounds/defaultSettings whenever followUserLocation is true). And the stale lastLocation short-circuits the corrective fitBounds at :125.

Worth knowing for repro fidelity: the tester walked "a few meters", but the background task only accepts a fix every 100 m (const.ts:5, enforced again at GPSDraftDetails.ts:144). So no new GPS point and no USER_LOCATION write occurred — the only thing that could have corrected the display is the native puck, which is exactly what the teardown killed.

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

Treat the offline→online transition in GPSMapView as a remount and clear the state that no longer reflects reality:

1. Add an effect keyed on isOffline. When it flips true → false, reset lastLocation to undefined and reset shouldUseImmediateFollowTransition back to noWaypoints || isTrackingGPS, so the rebuilt camera snaps to the puck instead of slowly animating in from the style default.
2. In the same effect, call getCurrentPosition() and setUserLocation(...) (mirroring what MapView.tsx:106-127 already does) so there is a fresh coordinate available immediately, without waiting for the 100 m threshold.
3. Also reset userInteractedWithMap on that transition. A pan the user did before going offline shouldn't permanently disable follow-mode on what is effectively a new map.

Together these make the map re-acquire and re-center on reconnect instead of rendering the pre-offline position.

Supporting evidence and alternatives considered

Ruled out — Mapbox tiles failing offline. While offline the app doesn't render a stale map at all; it shows PendingMapView ("The map will be generated when you go back online"). A tile or style fetch failure gives a blank/grey canvas, not a puck and route drawn at wrong coordinates. This is genuine coordinate/state staleness.

Ruled out — a server sync problem. There are no GPS API commands. Start/pause/resume/point-collection are all local Onyx.merge on GPS_DRAFT_DETAILS (GPSDraftDetails.ts); the trip only hits the server on Save. So there's no offline-queue or optimistic-data angle here.

Ruled out — point collection stops offline. It doesn't. The expo background task records coordinates regardless; isOffline only skips reverse geocoding (backgroundLocationTrackingTask/index.native.ts:49). The damage is confined to the map rendering path.

Not the cause — PR #99391. The issue lists it under "caught during regression testing", but that PR changed exactly one file (useUpdateGpsTripOnReconnect.ts, an OnyxUtils.get() → useOnyx refactor) and never touches the camera, the puck, lastLocation, or USER_LOCATION. Bug source is Exploratory — found while exploring around that PR, not caused by it.

Separate latent bug found nearby. useUpdateGpsTripOnReconnect.ts treats the last point of every segment as an "end" waypoint, including the currently-active one, and splices a reconnect-time snapshot back into the latest segment after an await. If a new GPS point lands during that await, it gets overwritten — a ≥100 m regression of the trip's leading end. It's a no-op in this particular repro (no new points), so it isn't the reported cause, but it's worth a separate look.

Not verified. Whether userInteractedWithMap was actually true in the tester's session (depends on whether they panned the map before going offline) — if it was, that alone reproduces the symptom, which is why fix #3 is included. I also could not confirm Mapbox Android's internal viewport-transition behavior on remount when no fix is yet available; those SDK internals aren't in the repo. This is a device-only, client-side flow, so there are no production logs that could confirm it — runtime evidence would need an Android repro with mock locations.

Related issues

No duplicates found. Nothing else open covers GPS tracking and offline reconnect.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[QichenZhu]

Note: the issue description is not accurate. From the video, the problem is that the map shows Atlantic City regardless of the actual position.

Reproduction steps for an Android emulator:

1. Set mock position 1.
2. Go offline.
3. Disable Location.
4. Go online.
5. Enable Location.
6. Set mock position 2.

Expected result:
The map shows mock position 2.

Actual result:
The map shows Atlantic City.