docs: close BUG-20 (trip IDs renumbered 1..10, sequence clamped)
This commit is contained in:
@@ -24,24 +24,21 @@ When CLOSED, move the entire entry to Resolved — don't duplicate.
|
||||
fills the cards immediately on load (and every 15 s) via REST. Needs in-car
|
||||
verification.
|
||||
|
||||
### BUG-20 — Server trip IDs inflate far beyond the real trip count
|
||||
- **Status**: `OPEN` 2026-08-14
|
||||
- **Phase**: 29
|
||||
- **Symptom**: the portal shows trip IDs in the tens of thousands (e.g. 25136, 27091) even
|
||||
though there are only ~10 real trips (verified: `COUNT=10`, `MAX(id)=27091`).
|
||||
- **Cause**: `trips.id` is `BIGSERIAL`, and `compute_trips_for_device()` upserts every trip on
|
||||
every tracking batch via `INSERT … ON CONFLICT (device_id, start_time) DO UPDATE`. PostgreSQL
|
||||
consumes a sequence value on every INSERT attempt — including the conflict/update path — so
|
||||
the sequence advances by the trip count on every recompute (which runs after every upload
|
||||
batch). Cosmetic only: nothing references `trips.id` as a foreign key (`deleted_trip_markers`
|
||||
keys on `(device_id, start_time)`).
|
||||
- **Fix**: clamp the sequence to `MAX(id)` after each recompute in `compute_trips_for_device()`,
|
||||
plus a one-time migration that renumbers existing trips compactly and resets the sequence.
|
||||
|
||||
---
|
||||
|
||||
## Resolved
|
||||
|
||||
### BUG-20 — Server trip IDs inflate far beyond the real trip count
|
||||
- **Status**: `CLOSED` 2026-08-14
|
||||
- **Commit**: `PENDING`
|
||||
- **Fix**: `trips.id BIGSERIAL` burned a sequence value on every upsert in
|
||||
`compute_trips_for_device()` (which runs after every upload batch), so IDs climbed far past
|
||||
the real trip count. Now the sequence is clamped to `MAX(id)` after each recompute
|
||||
(`server/modules/db.py`), and a one-time migration (`server/sql/migrate_phase29_trip_ids.sql`)
|
||||
renumbered existing trips compactly and reset the sequence.
|
||||
- **Verification**: before — `COUNT=10`, `MAX(id)=27091`; after — `MIN(id)=1`, `MAX(id)=10`,
|
||||
sequence `last_value=10` (next insert gets 11). API container rebuilt and healthy.
|
||||
|
||||
### BUG-18 — Pi needs offline timekeeping (no RTC)
|
||||
- **Status**: `CLOSED` 2026-08-14
|
||||
- **Commit**: `bf4f3d3`
|
||||
|
||||
@@ -2279,10 +2279,9 @@ logged as `BUG-XX` entries in [BUGS.md](./BUGS.md) (BUG-16 onward) and fixed + v
|
||||
`SET TIME!`). SIM868 CR1220 installed + its RTC set via `AT+CCLK` (was 2004 default); hold
|
||||
across power-off to confirm on next cycle. Optional follow-up: `AT+CCLK` boot-time clock
|
||||
fallback in `app_gps.py`.
|
||||
- **BUG-20 (server trip IDs inflate) — 🚧 IN PROGRESS**: `trips.id BIGSERIAL` burns sequence
|
||||
values on every upsert (recompute runs after each upload batch), so IDs run far past the real
|
||||
trip count (~10 trips, ids 27000+). Fix: clamp the sequence after each recompute + one-time
|
||||
renumber migration.
|
||||
- **BUG-20 (server trip IDs inflate) — ✅ FIXED**: `trips.id BIGSERIAL` burned sequence values
|
||||
on every upsert (recompute after each upload batch). Fixed: sequence clamped to `MAX(id)`
|
||||
after each recompute + one-time renumber migration — trips now 1..10, sequence at 10.
|
||||
|
||||
Open items from the drive — fill in as reported:
|
||||
- (none clock-related — BUG-17/BUG-18 closed 2026-08-14).
|
||||
|
||||
Reference in New Issue
Block a user