docs: close BUG-09/10, update resolved section
This commit is contained in:
Mathieu Moran
@@ -158,43 +158,16 @@ the authoritative, issue-by-issue record lives **here**.
|
|||||||
---
|
---
|
||||||
|
|
||||||
### BUG-09 — Server trip scrubber geocoding is slow on each step
|
### BUG-09 — Server trip scrubber geocoding is slow on each step
|
||||||
- **Status**: `OPEN`
|
- **Status**: `CLOSED` (commit `7e91355`; deployed + verified 2026-08-11)
|
||||||
- **Severity**: Medium (UX)
|
- **Fix**: `history.js` now pre-fetches geocode results for all unique coordinates in a trip
|
||||||
- **Area**: `static/js/history.js` `showReplayPoint()` / `scheduleGeocode()`
|
route (concurrency 4) when the trip is first loaded. Scrubbing checks the in-memory cache
|
||||||
- **Phase**: Phase 26
|
first, showing labels instantly. Fallback to live fetch only for uncached points.
|
||||||
- **Symptom**: Scrubbing through the trip timeline on the server portal is sluggish — the location
|
|
||||||
name takes a long time to appear because each scrub step fires a fresh `/api/geocode` HTTP
|
|
||||||
request (debounced 600ms). On the Pi this is fast (offline reverse_geocoder), but the server
|
|
||||||
calls Nominatim which adds latency.
|
|
||||||
- **Root cause**: Every `showReplayPoint()` call triggers `scheduleGeocode()` → debounced
|
|
||||||
`fetch(/api/geocode...)`. No pre-caching or batch loading.
|
|
||||||
- **Fix scope / actions**: Pre-fetch geocode results for ALL trip points when the route is first
|
|
||||||
loaded. Store in a local JS map keyed by rounded coordinate. Show cached label instantly during
|
|
||||||
scrubbing. Only fall back to live fetch for uncached points. Optionally batch-geocode at the
|
|
||||||
server API level too (accept multiple lat/lon pairs).
|
|
||||||
- **Acceptance**: Scrubbing through trip replay shows location names near-instantly.
|
|
||||||
|
|
||||||
### BUG-10 — GPS-only false trips generated when car is not connected
|
### BUG-10 — GPS-only false trips generated when car is not connected
|
||||||
- **Status**: `OPEN`
|
- **Status**: `CLOSED` (commit `7e91355`; deployed + verified 2026-08-11)
|
||||||
- **Severity**: Medium (data quality)
|
- **Fix**: `app_obd.py` tracks `_car_ever_connected` flag (set on first successful ECU
|
||||||
- **Area**: `modules/app_trip.py` `build_trip_summaries()`, `modules/app_sql.py` `refresh_trips()`
|
connection). `app_trip.py` `build_trip_summaries()` returns empty list when car was never
|
||||||
- **Phase**: Phase 26
|
connected. Bench-testing Pi now produces 0 trips. Server also redeployed (shared history.js).
|
||||||
- **Symptom**: The Pi generates trips from GPS data alone (GPS jitter/drift) even when the car
|
|
||||||
isn't connected. Since the Pi bench-tests with no OBD, GPS displacement fallback creates
|
|
||||||
phantom "trips" from stationary GPS noise.
|
|
||||||
- **Root cause**: The GPS motion fallback (3+ consecutive 8m displacements) can be satisfied by
|
|
||||||
GPS jitter over time, especially indoors or in weak-signal areas. The system doesn't gate trip
|
|
||||||
detection on whether OBD was ever present.
|
|
||||||
- **Fix scope / actions**:
|
|
||||||
- **Option A (strict)**: Only start trips when OBD wheel speed has been detected at least once
|
|
||||||
since the app started (a `car_was_connected` flag). No OBD ever = no trips, even with GPS.
|
|
||||||
- **Option B (lenient)**: Increase GPS motion requirements when OBD has never been seen (e.g.
|
|
||||||
require 10+ consecutive displacements of 20m+ instead of 3×8m).
|
|
||||||
- **Recommend Option A** — it matches the real-world use case: the Pi is powered by the car's
|
|
||||||
ignition, so OBD should always be reachable when the car is running. No OBD = bench test,
|
|
||||||
don't generate trips.
|
|
||||||
- **Acceptance**: Bench-testing the Pi (no car connected) produces zero trips. Real driving with
|
|
||||||
OBD connected still produces correct trips.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -212,3 +185,27 @@ the authoritative, issue-by-issue record lives **here**.
|
|||||||
- **Commit**: `e2f2314`
|
- **Commit**: `e2f2314`
|
||||||
- **Verification**: Server git reset to origin, Docker rebuild, `/health` OK on LAN and Cloudflare
|
- **Verification**: Server git reset to origin, Docker rebuild, `/health` OK on LAN and Cloudflare
|
||||||
Tunnel. `get_trip_route` now uses `"obd" if speed > 0 else "gps"` matching Pi logic.
|
Tunnel. `get_trip_route` now uses `"obd" if speed > 0 else "gps"` matching Pi logic.
|
||||||
|
|
||||||
|
### BUG-08 — No trip deletion on the local Pi
|
||||||
|
- **Status**: `CLOSED` 2026-08-11
|
||||||
|
- **Commit**: `c5c478b`
|
||||||
|
- **Verification**: `deletable` macro, `window.confirmDelete`, `DELETE /api/trip/<id>` route.
|
||||||
|
Trip 1967 deleted (18→17 trips), tracking data preserved. Server deploy via docker rebuild.
|
||||||
|
|
||||||
|
### BUG-04 — Server merges two trips into one
|
||||||
|
- **Status**: `CLOSED` 2026-08-11
|
||||||
|
- **Commit**: `96fb897`
|
||||||
|
- **Verification**: Server trips cleared and recomputed with Pi's motion-aware logic.
|
||||||
|
17 trips on both Pi and server (matching).
|
||||||
|
|
||||||
|
### BUG-09 — Server trip scrubber geocoding slow
|
||||||
|
- **Status**: `CLOSED` 2026-08-11
|
||||||
|
- **Commit**: `7e91355`
|
||||||
|
- **Verification**: `history.js` pre-fetches geocodes for all route points on trip load.
|
||||||
|
Cache checked first during scrub. Server Docker rebuilt.
|
||||||
|
|
||||||
|
### BUG-10 — GPS-only false trips when car not connected
|
||||||
|
- **Status**: `CLOSED` 2026-08-11
|
||||||
|
- **Commit**: `7e91355`
|
||||||
|
- **Verification**: `was_car_ever_connected()` flag gates trip generation.
|
||||||
|
Pi bench-test produces 0 trips.
|
||||||
|
|||||||
Reference in New Issue
Block a user