Description
Since v3.0.0 (#86) the own vessel's positions are recorded to SQLite indefinitely. The v1 collection route GET /signalk/v1/api/tracks has no default time window: allTracksHandler calls getFilteredTracks → getFilteredTimedTracks → rowsFor(context, undefined), which runs SELECT ... WHERE context = ? ORDER BY timestamp over every row for that context, and thin(points, undefined) returns the rows untouched. A v1 client that passes only radius therefore receives the whole own-vessel track since installation, and the response grows without bound.
The v2 provider is protected by maxPoints (#79) and simplify/epsilon (#89), but those do not apply to the v1 routes, and servers below 2.33.0 have only the v1 routes.
The README table lists a setting "Days of the own vessel's track to keep", but the shipped schema has no such property; SqliteTrackStore is constructed with retention: 0 and prune() skips app.selfContext.
Concrete case
A vessel that spends weeks at anchor with resolution: 1000 (the value hoekens-anchor-alarm recommends so the swing track has 1 s detail) stores 86,400 rows per day. hoekens-anchor-alarm 2.13.0 fetches /signalk/v1/api/tracks?radius=<n> on every page load and pushes the result through Leaflet.hotline; at 1 s resolution one month of anchoring is 2.6 million points and roughly 60 MB of JSON (measured by serialising a synthetic month at N2K coordinate precision), and it keeps growing. Under v2.x the same call was bounded by pointsToKeep (24 h at that resolution).
Server: Signal K 2.33.0, Node 24.21.0, plugin 3.0.0.
Options
- An own-vessel retention setting (days, 0 = keep everything), applied by the existing
prune() pass alongside aisRetentionDays. This is what the README already describes.
- A default window on the windowless v1 routes, e.g. 24 h to match the previous
pointsToKeep behaviour and WINDOWLESS_HISTORY_SPAN_MS, with the full store still reachable through explicit from/to.
Either resolves the case above; both together would be the least surprising. Happy to open a PR for whichever direction is preferred.
Description
Since v3.0.0 (#86) the own vessel's positions are recorded to SQLite indefinitely. The v1 collection route
GET /signalk/v1/api/trackshas no default time window:allTracksHandlercallsgetFilteredTracks→getFilteredTimedTracks→rowsFor(context, undefined), which runsSELECT ... WHERE context = ? ORDER BY timestampover every row for that context, andthin(points, undefined)returns the rows untouched. A v1 client that passes onlyradiustherefore receives the whole own-vessel track since installation, and the response grows without bound.The v2 provider is protected by
maxPoints(#79) andsimplify/epsilon(#89), but those do not apply to the v1 routes, and servers below 2.33.0 have only the v1 routes.The README table lists a setting "Days of the own vessel's track to keep", but the shipped schema has no such property;
SqliteTrackStoreis constructed withretention: 0andprune()skipsapp.selfContext.Concrete case
A vessel that spends weeks at anchor with
resolution: 1000(the value hoekens-anchor-alarm recommends so the swing track has 1 s detail) stores 86,400 rows per day. hoekens-anchor-alarm 2.13.0 fetches/signalk/v1/api/tracks?radius=<n>on every page load and pushes the result through Leaflet.hotline; at 1 s resolution one month of anchoring is 2.6 million points and roughly 60 MB of JSON (measured by serialising a synthetic month at N2K coordinate precision), and it keeps growing. Under v2.x the same call was bounded bypointsToKeep(24 h at that resolution).Server: Signal K 2.33.0, Node 24.21.0, plugin 3.0.0.
Options
prune()pass alongsideaisRetentionDays. This is what the README already describes.pointsToKeepbehaviour andWINDOWLESS_HISTORY_SPAN_MS, with the full store still reachable through explicitfrom/to.Either resolves the case above; both together would be the least surprising. Happy to open a PR for whichever direction is preferred.