research/comuline-krl-data/analysis.md

Analysis — how comuline works

Pipeline

1. Sync (daily cron, as designed): comuline/api/src/sync/station.ts fetches {KRL_ENDPOINT_BASE_URL}/krl-station; schedule.ts then iterates all stations in batches of 5 (5 s sleep between) — CORS OPTIONS preflight, then GET /schedule?stationid={id}&timefrom=00:00&timeto=23:00. Requests carry browser-like headers plus a hardcoded bearer token, because the upstream is an authenticated partner API.
2. Transform: stations → st_krl_<id> records (upstream WIL entries filtered; airport station BST manually added); schedules → sc_krl_<station>_<train> rows with origin/destination station IDs resolved by name, departs_at/arrives_at timestamps, and line color; upserted into Postgres.
3. Serve: Hono API on Cloudflare Workers (Neon Postgres + Upstash Redis per-station read cache) exposes clean JSON with an OpenAPI spec; web/native apps consume it.

KRL_ENDPOINT_BASE_URL = https://api-partner.krl.co.id/krl-webs/v1 (from the repo's .dev.example.vars).

Data model (public API)

• Station: { uid, id (e.g. MRI), name, type (KRL|LOCAL), metadata.origin.{daop,fg_enable}, active }
• Schedule row: { id, station_id, station_origin_id, station_destination_id, train_id (e.g. 1448B), line ("COMMUTER LINE BOGOR"), route ("JAKARTAKOTA-DEPOK"), departs_at, arrives_at, metadata.origin.color }
• Route view (/v1/route/{train_id}): ordered stop sequence (station name + departure time) for one train.

Observed state (2026-10-12)

• 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, and it is an operational stop: the official upstream API was not freshness-assessed (no credentialed access, by design), and repo evidence (below) shows the upstream kept evolving while comuline stopped following. A frozen replica does not imply a broken upstream.
• No realtime tracking: no position/GPS data in the bundle or API. The product is schedule lookup with locally saved stations.

Why the sync stopped — repo evidence (verified 2026-10-12)

• Last successful sync = 2025-03-30 ~14:49 UTC (newest updated_at passes) — ~20 minutes after the day's last merge (PR #11 merged 14:29 UTC). Nothing since; operations just stopped.
• There is no automation in the repo at all. No cron triggers in worker config (checked wrangler.toml pre-v4 and the current wrangler.jsonc), no scheduled GitHub workflow (only PR-build + push-deploy), and no scheduled() handler in the worker entry (export default app — a Cloudflare Cron Trigger could not even fire). The README's "daily cron at 00:00" therefore lived outside the codebase — manual/CLI runs or a machine-local crontab (inferred). No reproducible scheduling infrastructure was ever shipped.
• The official side kept moving; comuline needed repeated adaptation:
  • endpoint path …/krlweb/v1 → …/krl-webs/v1 (absorbed by PR #11, merged 2025-03-30);
  • endpoint /schedule → /schedules (PR #16, opened 2026-01-26, still open/unmerged);
  • tokens rotate ~yearly: main's hardcoded token expired 2025-08-02; the newer token shown in PR #16 was minted 2025-08-06 (exp 2026-08-06), obtained "from the official web app network request" per that PR's README change.
• Maintainer dormant on this project, active on GitHub generally: unmerged since early 2025 — PR #14 (MRT support, 2025-04-01), PR #16 (2026-01-26), issues #15 (TransJakarta request, 2025-11-12), #17 (Jatake station, 2026-02-01); web repo: issue #16 + PR #17 open since Apr 2025. The author's public GitHub events show activity as recent as this week — just not on comuline.
• Verdict: the stale side is comuline — its data copy and its abandoned operations; the official KRL side is alive and has drifted (path renames, token rotation). As shipped, comuline's sync would fail today on both counts (expired token; outdated paths). Confidence: established for repo facts/timestamps; "cron ran externally" inferred; upstream's exact current state not assessed (no credentialed calls).

Boundaries respected (deliberate limits)

• Upstream api-partner.krl.co.id was probed once without credentials (returned 404) to characterize the auth wall.
• No calls were made using the tokens published in the public repo/PRs (values not reproduced in this vault — including the newer one in PR #16).
• No attempts to bypass auth, rate limits, or access controls.

Confidence

• Established: pipeline structure and architecture (public source + live API); coverage counts; staleness timestamps; absence of live tracking; upstream URL and auth wall; the stop timeline and absence of in-repo automation (repo history).
• Inferred: the sync ran manually/externally — machine-local cron or CLI habit; operational abandonment is the freeze cause.
• Not assessed: current upstream state and exact API shape today (no credentialed access).

Artifacts

• Evidence archive: workspace/comuline-captures/ — page HTML + headers, web bundle, live API samples (stations.json, sched_MRI.json, openapi.json), sync sources (bearer token REDACTED in the archive copy), dev.example.vars.