0xrsydn/research
1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Clarify staleness scope in comuline-krl-data analysis (replica vs upstream)

Browse source
This commit is contained in:
hermes 2026-10-12 12:51:20 +00:00
commit f0a61c74a8
1 changed files with 1 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
comuline-krl-data/analysis.md
View file

@ -18,6 +18,7 @@
- API live; 113 stations served. Row counts sampled: MRI 1,045 · DP 730 · CLT 683 · JAKK 367 · BOO 341 · TNG 84 · BEK 0 (station present, no schedule rows).
- **Freshness:** the newest `updated_at` values are bulk 2024-11-13 and partial re-sync 2025-03-30; nothing newer. Repo activity stops the same month (`api` last push 2025-03-30). Conclusion: the daily cron is not currently running; the data is a frozen snapshot (~18 months old as of this audit).
- **Scope of that staleness — comuline's replicated copy only:** the official upstream API (`api-partner.krl.co.id`) was **not** freshness-assessed (no credentialed access, by design). A frozen replica does not imply a broken upstream. Timeline note: the hardcoded token remained valid until 2025-08-02, so token expiry does not explain the ~2025-03-30 sync stop; comuline's own sync mechanism stopping does (inferred cause — external scheduler/manual runs; no cron trigger exists in the repo's worker config or workflows).
- **No realtime tracking:** no position/GPS data in the bundle or API. The product is schedule lookup with locally saved stations.
## Boundaries respected (deliberate limits)