Mobile callsign history stops at 1000 packets with no sign that it was truncated #56

New issue

Open

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

skippy-bot commented

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

Problem

subscribe_callsign accepts hours_back up to 168 and documents that history follows, but the replay is a hard-coded 1000 rows, newest first. A busy station asked for 24 hours arrives starting partway into the window, with no count, no cursor and no truncation flag, so a plotted track silently begins late.

Evidence

At 2f150f66:

lib/aprsme_web/channels/mobile_channel.ex:715 calls Packets.get_callsign_history(callsign, hours_back, 1000) with a literal limit the payload cannot change.
lib/aprsme/packets.ex:470 orders descending with limit: ^clamp_limit(limit), so the newest rows win and the rest of the window is dropped.
docs/mobile-api.md:326 documents hours_back with a maximum of 168 and no packet cap.
docs/mobile-api.md:71 shows that subscribe_bounds already takes a documented limit, so the shape exists in this API.

Expected

Either load the requested window, or take a documented limit and report when the replay was truncated, in the same style as subscribe_bounds.

How to verify

Insert 1500 packets for one sender across 24 hours, push subscribe_callsign with hours_back: 24, and sum the packets events: they total 1000.

Acceptance criteria

The client can request the number of historical rows it needs, or is told the replay was truncated.
The docs state the cap the server enforces.
A test sums the replayed packets for a station with more than 1000 rows.

Effort: S
Lens: api

## Problem `subscribe_callsign` accepts `hours_back` up to 168 and documents that history follows, but the replay is a hard-coded 1000 rows, newest first. A busy station asked for 24 hours arrives starting partway into the window, with no count, no cursor and no truncation flag, so a plotted track silently begins late. ## Evidence At `2f150f66`: - `lib/aprsme_web/channels/mobile_channel.ex:715` calls `Packets.get_callsign_history(callsign, hours_back, 1000)` with a literal limit the payload cannot change. - `lib/aprsme/packets.ex:470` orders descending with `limit: ^clamp_limit(limit)`, so the newest rows win and the rest of the window is dropped. - `docs/mobile-api.md:326` documents `hours_back` with a maximum of 168 and no packet cap. - `docs/mobile-api.md:71` shows that `subscribe_bounds` already takes a documented `limit`, so the shape exists in this API. ## Expected Either load the requested window, or take a documented limit and report when the replay was truncated, in the same style as `subscribe_bounds`. ## How to verify Insert 1500 packets for one sender across 24 hours, push `subscribe_callsign` with `hours_back: 24`, and sum the packets events: they total 1000. ## Acceptance criteria - [ ] The client can request the number of historical rows it needs, or is told the replay was truncated. - [ ] The docs state the cap the server enforces. - [ ] A test sums the replayed packets for a station with more than 1000 rows. **Effort:** S **Lens:** api

skippy-bot added the

Medium

bug

effort: S

labels

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