What happens
Reported from a Trace Mode session: the "distance to previous ping" readout showed several kilometers when the real distance to the previous trace was about 100 m. The value grew while driving away from the session's starting point and shrank when driving back toward it, so it was clearly anchored to the start of the session, not the previous ping. Meanwhile the skip logic behaved correctly: stopping while the readout said "several km" still produced "too close, skipping".
The report came from a pre-1.3.0 dev build, but the defect is still present in the current code.
Why
There are three separate "last ping position" anchors, and the readout only follows one of them:
- The map readout (
map_widget.dart, via AppStateProvider.distanceFromLastPing) reads GpsService._lastPingPosition.
_lastPingPosition is only ever set by markPingPosition(), which is called from the TX ping path in ping_service.dart. Nothing in the trace or discovery paths touches it.- Trace Mode's own 25 m skip check uses
_lastTargetedPosition, and Passive Mode uses _lastDiscoveryPosition, both private to PingService and updated per trace/discovery.
So in a session that sends no TX pings (Trace Mode, Passive Mode), the displayed distance stays measured from wherever the last TX ping happened, which is typically the session start. The skip logic and the readout disagree because they read different anchors.
Suggested direction
Either update the shared display anchor whenever any ping type actually fires (TX, discovery, trace), or make the readout mode-aware so it reads the same anchor the active mode's skip check uses. The first option is a one-line addition in each of the trace and discovery send paths.
What happens
Reported from a Trace Mode session: the "distance to previous ping" readout showed several kilometers when the real distance to the previous trace was about 100 m. The value grew while driving away from the session's starting point and shrank when driving back toward it, so it was clearly anchored to the start of the session, not the previous ping. Meanwhile the skip logic behaved correctly: stopping while the readout said "several km" still produced "too close, skipping".
The report came from a pre-1.3.0 dev build, but the defect is still present in the current code.
Why
There are three separate "last ping position" anchors, and the readout only follows one of them:
map_widget.dart, viaAppStateProvider.distanceFromLastPing) readsGpsService._lastPingPosition._lastPingPositionis only ever set bymarkPingPosition(), which is called from the TX ping path inping_service.dart. Nothing in the trace or discovery paths touches it._lastTargetedPosition, and Passive Mode uses_lastDiscoveryPosition, both private toPingServiceand updated per trace/discovery.So in a session that sends no TX pings (Trace Mode, Passive Mode), the displayed distance stays measured from wherever the last TX ping happened, which is typically the session start. The skip logic and the readout disagree because they read different anchors.
Suggested direction
Either update the shared display anchor whenever any ping type actually fires (TX, discovery, trace), or make the readout mode-aware so it reads the same anchor the active mode's skip check uses. The first option is a one-line addition in each of the trace and discovery send paths.