Production keeps one day of packets while the map offers a one week trail and the info page aggregates 30 days #51

New issue

Open

opened 2026-11-03 18:52:28 +00:00 by skippy-bot · 0 comments

skippy-bot commented

2026-11-03 18:52:28 +00:00

Problem

The deployment sets PACKET_RETENTION_DAYS to 1, so drop_old_partitions keeps only yesterday and today. The map still offers 48 hour and 1 week trails, and /info/:callsign builds its stations-heard tables from a 30 day window. Choosing 1 Week draws about a day and a half of track and then stops with no indication that history was pruned, and the info page's first heard, last heard and packet counts can only ever reflect about two days.

Evidence

At 2f150f66:

k8s/deployment.yaml:175 sets PACKET_RETENTION_DAYS and :176 is value: "1".
config/runtime.exs:284 reads that value with a default of 7, so production is the deployment's choice, not the code default.
lib/aprsme/partition_manager.ex:90 computes the drop cutoff as now minus retention, and :98 drops any partition whose upper bound is at or before it.
lib/aprsme_web/live/map_live/index.ex:1060 offers a 48 hour option and :1063 a 1 Week option, applied as a server cut at lib/aprsme_web/live/map_live/index.ex:47.
lib/aprsme_web/live/info_live/show.ex:428 builds one_month_ago = DateTime.shift(DateTime.utc_now(), day: -30).

Expected

Either retention covers the longest window the UI offers (7 days or more in the deployment), or the trail selector and the info page cap their windows at the configured retention and say so. Offering a window the database cannot answer is the defect.

How to verify

In production, SELECT min(received_at) FROM packets, then load /?trail=168 and note that the oldest trail point is about a day old. A cheap regression test asserts every value parse_trail_duration/1 accepts is within packet_retention_days.

Acceptance criteria

The configured retention covers every window the UI offers, or the UI clamps to it.
The info page's 30 day aggregates either match retention or state the window they actually use.
A test ties the trail options to the configured retention.

Effort: S
Lens: product

## Problem The deployment sets `PACKET_RETENTION_DAYS` to 1, so `drop_old_partitions` keeps only yesterday and today. The map still offers 48 hour and 1 week trails, and `/info/:callsign` builds its stations-heard tables from a 30 day window. Choosing 1 Week draws about a day and a half of track and then stops with no indication that history was pruned, and the info page's first heard, last heard and packet counts can only ever reflect about two days. ## Evidence At `2f150f66`: - `k8s/deployment.yaml:175` sets `PACKET_RETENTION_DAYS` and `:176` is `value: "1"`. - `config/runtime.exs:284` reads that value with a default of 7, so production is the deployment's choice, not the code default. - `lib/aprsme/partition_manager.ex:90` computes the drop cutoff as now minus retention, and `:98` drops any partition whose upper bound is at or before it. - `lib/aprsme_web/live/map_live/index.ex:1060` offers a 48 hour option and `:1063` a 1 Week option, applied as a server cut at `lib/aprsme_web/live/map_live/index.ex:47`. - `lib/aprsme_web/live/info_live/show.ex:428` builds `one_month_ago = DateTime.shift(DateTime.utc_now(), day: -30)`. ## Expected Either retention covers the longest window the UI offers (7 days or more in the deployment), or the trail selector and the info page cap their windows at the configured retention and say so. Offering a window the database cannot answer is the defect. ## How to verify In production, `SELECT min(received_at) FROM packets`, then load `/?trail=168` and note that the oldest trail point is about a day old. A cheap regression test asserts every value `parse_trail_duration/1` accepts is within `packet_retention_days`. ## Acceptance criteria - [ ] The configured retention covers every window the UI offers, or the UI clamps to it. - [ ] The info page's 30 day aggregates either match retention or state the window they actually use. - [ ] A test ties the trail options to the configured retention. **Effort:** S **Lens:** product

skippy-bot added the

Medium

bug

effort: S

labels

2026-11-03 18:52:28 +00:00