Found during e2e testing against a live server (signalk-server 2.32.0 with SignalK/signalk-server#2995, @signalk/tracks-plugin@3.0.0-beta.1, signalk-questdb 2.1.4, live NMEA 2000 + AIS).
The v2 provider cannot answer for any period before the plugin was installed or last restarted. The v1 route can, because it reconciles the History API in.
Measured on the same vessel and the same one-hour window, with the plugin having started at 05:53:
|
span returned |
points |
GET /signalk/v1/api/self/track?timespan=1h |
05:24 → 06:23 |
60 |
GET /signalk/v2/api/tracks?contexts=self&duration=PT1H |
05:53 → 06:22 |
30 |
QuestDB holds 29 rows for 05:24–05:53, the window before the plugin existed. That is exactly the difference: v1 returns the plugin's 30 stored points plus QuestDB's 29, v2 returns the store alone. src/trackProvider.ts has no history reference.
Scope, stated honestly. This is not a permanent shortfall that grows — the gap is bounded by how much history predates the store, and it closes as the store fills. It bites in three cases:
- immediately after install, which is when someone is most likely to be evaluating the plugin
- after a restart with
source: memory, where the store starts empty every time
- where a history provider holds months or years predating the plugin
I first wrote this up as "v2 answers with almost nothing", from a measurement taken three minutes after startup (2 points vs 60). That number was an artefact of the timing, and overstated it. The durable statement is the one above.
Two ways to close it, pointing in opposite directions:
-
Reconcile in the provider, as the v1 route already does. Small — reconcile() and historyPositions() are both extracted and tested. But one provider would then answer with another's data, and the providerId on that feature would misattribute where the points came from.
-
Let a history-shaped store register its own Track provider. The fan-out in #2995 exists for this, @motamman is building exactly that for signalk-parquet, and each feature carries the providerId that actually produced it.
I think 2 is right and 1 is a shortcut worth avoiding, but 2 depends on other people's plugins and nothing implements it today. Raised on SignalK/signalk-server#2504 for a view before implementing either, since doing 1 quietly would settle the question by shipping.
Found during e2e testing against a live server (signalk-server 2.32.0 with SignalK/signalk-server#2995,
@signalk/tracks-plugin@3.0.0-beta.1, signalk-questdb 2.1.4, live NMEA 2000 + AIS).The v2 provider cannot answer for any period before the plugin was installed or last restarted. The v1 route can, because it reconciles the History API in.
Measured on the same vessel and the same one-hour window, with the plugin having started at 05:53:
GET /signalk/v1/api/self/track?timespan=1hGET /signalk/v2/api/tracks?contexts=self&duration=PT1HQuestDB holds 29 rows for 05:24–05:53, the window before the plugin existed. That is exactly the difference: v1 returns the plugin's 30 stored points plus QuestDB's 29, v2 returns the store alone.
src/trackProvider.tshas no history reference.Scope, stated honestly. This is not a permanent shortfall that grows — the gap is bounded by how much history predates the store, and it closes as the store fills. It bites in three cases:
source: memory, where the store starts empty every timeI first wrote this up as "v2 answers with almost nothing", from a measurement taken three minutes after startup (2 points vs 60). That number was an artefact of the timing, and overstated it. The durable statement is the one above.
Two ways to close it, pointing in opposite directions:
Reconcile in the provider, as the v1 route already does. Small —
reconcile()andhistoryPositions()are both extracted and tested. But one provider would then answer with another's data, and theproviderIdon that feature would misattribute where the points came from.Let a history-shaped store register its own Track provider. The fan-out in #2995 exists for this, @motamman is building exactly that for signalk-parquet, and each feature carries the
providerIdthat actually produced it.I think 2 is right and 1 is a shortcut worth avoiding, but 2 depends on other people's plugins and nothing implements it today. Raised on SignalK/signalk-server#2504 for a view before implementing either, since doing 1 quietly would settle the question by shipping.