Traceroute map position snapshots#4035
Conversation
Store per-traceroute node position snapshots in Room and prefer them when rendering traceroute maps, so historical traceroutes show positions from completion time.
4477570 to
7eeca2b
Compare
There was a problem hiding this comment.
Pull request overview
This PR implements traceroute map position snapshots by storing node positions at the time a traceroute response is received. This allows traceroute maps to display historical node positions rather than current locations, providing a more accurate representation of where nodes were during the actual traceroute.
Key Changes:
- New database table (
traceroute_node_position) with foreign key to mesh logs for automatic cleanup - Position snapshot capture in
MeshServicewhen full traceroute responses are processed - Map views updated to accept and display snapshot positions with fallback to current positions
- Navigation and UI components updated to pass
logUuidthrough the flow
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
TracerouteNodePositionEntity.kt |
New database entity for storing position snapshots with composite primary key |
TracerouteNodePositionDao.kt |
DAO interface for accessing snapshot position data |
MeshtasticDatabase.kt |
Database version bump to 25 with auto-migration for new table |
TracerouteSnapshotRepository.kt |
Repository managing snapshot position CRUD operations |
MeshService.kt |
Captures position snapshots when traceroute responses arrive, tracks logUuid lifecycle |
MetricsViewModel.kt |
Exposes snapshot positions flow to UI layer |
TracerouteMapScreen.kt |
Accepts optional logUuid and snapshot positions, refactored into scaffold pattern |
TracerouteLog.kt |
Updated dialog to include logUuid and use snapshot positions for map availability check |
BaseMapViewModel.kt |
Extension function for node selection logic handling snapshot vs current positions |
MapView.kt (both variants) |
Updated to accept and use snapshot positions for traceroute display |
Routes.kt |
Navigation route updated with optional logUuid parameter |
Main.kt |
Passes logUuid when navigating to traceroute map from service response |
NodesNavigation.kt |
Navigation handler updated to pass logUuid to traceroute map |
ServiceRepository.kt |
TracerouteResponse data class updated with optional logUuid field |
DatabaseModule.kt |
DI binding for new TracerouteNodePositionDao |
25.json |
Database schema export for version 25 |
…/TracerouteNodePositionDao.kt Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Jord <650645+DivineOmega@users.noreply.github.com>
|
Unrelated to co-pilot's earlier comment, there might be a race condition related to both However, I'll see if I can put something in to guard against it. Should be fixed in 8a3755a. Difficult to test though, as it's extremely unlikely this would occur in reality. |
Appreciate it - this one turned into a bigger beast than expected 😅 |
…/TracerouteNodePositionDao.kt Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Jord <650645+DivineOmega@users.noreply.github.com>
|
Moved PR to draft to do some more local testing. |
|
Okay, this all seems to be working. Ready for re-review. |
jamesarich
left a comment
There was a problem hiding this comment.
Let's give it a spin 😵💫
|
I'd appreciate some other people testing it after merge as well. I've done several tests myself, but there's barely any movement in my local nodes (at least those that I can reliably traceroute). Also, worth noting for anyone testing this: Old traceroutes, prior to this feature being implemented, will just show the current (latest) positions. Only new traceroutes will have their position info snapshotted. |
I'll cut it into an internal build shortly, which our devs and testers usually snag right away - we should find out soon 👍 |
Great, thank you! |
This PR addresses #4033 by storing the current (last known) position data for all related nodes in a new DB table (
traceroute_node_position) when a traceroute response is processed by theMeshService.This data is then used by the traceroute map screens to display the traceroute with the nodes positioned where they were at the time the traceroute took place. If the position information can not be found in the
traceroute_node_positiontable for whatever reason (e.g. traceroute logs stored prior to this feature being implemented), the map will fallback to using the more recent (current) locations.