Informal / idea — not fully specced.
Motivation
The GTFS extract is gitignored and must be present on disk for schedule-derived line status (#26/#27) to work. When it's stale (its calendar_dates no longer cover today's service date) the provider fails open and nothing dims — which is exactly the failure we just hit (the bundled feed had expired months earlier).
We now have a helper to refresh it: download_gtfs_extract() / python -m app.utils.gtfs_utils. But refreshing is currently a manual step someone has to remember. The feed I pulled only covers through ~2026-09-04, then it goes stale again.
Rough idea
On container boot (or as a lightweight periodic check), verify the extract covers today and refresh it if not:
- At startup, check whether the loaded schedule
covers(today) (the check already exists on ScheduleData). If not — or if the files are missing entirely — call download_gtfs_extract() before serving.
- Possibly a periodic re-check (daily) so a long-running container doesn't drift stale mid-deployment. Could piggyback on the existing refresh loop or a separate low-frequency task.
Open questions / things to decide
- Boot-time cost: downloading + extracting ~100 MB of
stop_times and regenerating shapes on every boot is heavy. Gate it on covers(today) being false, and/or cache by feed version (feed_info.txt has a feed date).
- Failure handling: network down at boot → must not block startup; fall back to whatever extract is on disk (fail open is already the safe default).
- Volume vs image: the extract is a mounted host volume in
compose.yaml, so a refresh persists across restarts (good) but is shared with the host — decide whether boot-refresh writes to the mount.
- Freshness signal:
feed_info.txt feed_end_date, or the calendar_dates max, could drive a "should refresh" decision without downloading.
- Not necessarily boot — a scheduled routine/cron that refreshes weekly might be simpler and avoids slow boots.
No acceptance criteria yet — capturing the idea so the stale-feed failure mode doesn't silently recur.
Motivation
The GTFS extract is gitignored and must be present on disk for schedule-derived line status (#26/#27) to work. When it's stale (its
calendar_datesno longer cover today's service date) the provider fails open and nothing dims — which is exactly the failure we just hit (the bundled feed had expired months earlier).We now have a helper to refresh it:
download_gtfs_extract()/python -m app.utils.gtfs_utils. But refreshing is currently a manual step someone has to remember. The feed I pulled only covers through ~2026-09-04, then it goes stale again.Rough idea
On container boot (or as a lightweight periodic check), verify the extract covers today and refresh it if not:
covers(today)(the check already exists onScheduleData). If not — or if the files are missing entirely — calldownload_gtfs_extract()before serving.Open questions / things to decide
stop_timesand regenerating shapes on every boot is heavy. Gate it oncovers(today)being false, and/or cache by feed version (feed_info.txthas a feed date).compose.yaml, so a refresh persists across restarts (good) but is shared with the host — decide whether boot-refresh writes to the mount.feed_info.txtfeed_end_date, or thecalendar_datesmax, could drive a "should refresh" decision without downloading.No acceptance criteria yet — capturing the idea so the stale-feed failure mode doesn't silently recur.