docs: close BUG-20 (trip IDs renumbered 1..10, sequence clamped)

This commit is contained in:
Mathieu Moran
2026-08-14 22:05:09 -04:00
parent 01c7fdf0c4
commit 9af71e2395
2 changed files with 14 additions and 18 deletions
+11 -14
View File
@@ -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 fills the cards immediately on load (and every 15 s) via REST. Needs in-car
verification. 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 ## 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) ### BUG-18 — Pi needs offline timekeeping (no RTC)
- **Status**: `CLOSED` 2026-08-14 - **Status**: `CLOSED` 2026-08-14
- **Commit**: `bf4f3d3` - **Commit**: `bf4f3d3`
+3 -4
View File
@@ -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 `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 across power-off to confirm on next cycle. Optional follow-up: `AT+CCLK` boot-time clock
fallback in `app_gps.py`. fallback in `app_gps.py`.
- **BUG-20 (server trip IDs inflate) — 🚧 IN PROGRESS**: `trips.id BIGSERIAL` burns sequence - **BUG-20 (server trip IDs inflate) — ✅ FIXED**: `trips.id BIGSERIAL` burned sequence values
values on every upsert (recompute runs after each upload batch), so IDs run far past the real on every upsert (recompute after each upload batch). Fixed: sequence clamped to `MAX(id)`
trip count (~10 trips, ids 27000+). Fix: clamp the sequence after each recompute + one-time after each recompute + one-time renumber migration — trips now 1..10, sequence at 10.
renumber migration.
Open items from the drive — fill in as reported: Open items from the drive — fill in as reported:
- (none clock-related — BUG-17/BUG-18 closed 2026-08-14). - (none clock-related — BUG-17/BUG-18 closed 2026-08-14).