fix(db): give the holiday stamping backfill its own migration version and reuse the stamping path #244

New issue

Open

opened 2026-10-03 08:47:07 +00:00 by gabogg · 0 comments

gabogg commented

2026-10-03 08:47:07 +00:00

Owner

P3 follow-up from PR #178 review pass 4 (both axes).

Finding

The version key is reused. The migration step that stamps past is_holiday=1 entries with no business-day record (app/db/database.py ~513-568) is registered under 20261002_holiday_backfill. That is the same version an earlier PR #178 head (a420921) already recorded without this step. Any database that ran a420921 skips it, so its never-stamped holidays still split the readers.
The stamping logic is copied. The step re-implements stamping inline:
- It hand-rolls planned_for and opening_hours_by_schedule.
- It hard-codes "04:00", "10:00", "18:00" and "Feriado" instead of DEFAULT_RESET_TIME, DEFAULT_HOLIDAY_HOURS and configured_holiday_hours.
- It builds the audit dict by hand instead of asdict(BusinessDaySchedule).
The resolver and the migration can drift apart, and the pass-3 fix reply said records are created "strictly through the stamping path".

Acceptance Criteria

The stamping step has its own migration version, and it is idempotent, so a DB that already ran the old key still gets it.
The rows are built with the same helpers as stamp_business_day_schedules_async. No duplicated literals.
A test: a DB with 20261002_holiday_backfill already recorded and an unstamped past holiday gets a record and a STAMP audit row on startup.

P3 follow-up from PR #178 review pass 4 (both axes). ### Finding - **The version key is reused.** The migration step that stamps past `is_holiday=1` entries with no business-day record (`app/db/database.py` ~513-568) is registered under `20261002_holiday_backfill`. That is the same version an earlier PR #178 head (`a420921`) already recorded without this step. Any database that ran `a420921` skips it, so its never-stamped holidays still split the readers. - **The stamping logic is copied.** The step re-implements stamping inline: - It hand-rolls `planned_for` and `opening_hours_by_schedule`. - It hard-codes `"04:00"`, `"10:00"`, `"18:00"` and `"Feriado"` instead of `DEFAULT_RESET_TIME`, `DEFAULT_HOLIDAY_HOURS` and `configured_holiday_hours`. - It builds the audit dict by hand instead of `asdict(BusinessDaySchedule)`. The resolver and the migration can drift apart, and the pass-3 fix reply said records are created "strictly through the stamping path". ### Acceptance Criteria - The stamping step has its own migration version, and it is idempotent, so a DB that already ran the old key still gets it. - The rows are built with the same helpers as `stamp_business_day_schedules_async`. No duplicated literals. - A test: a DB with `20261002_holiday_backfill` already recorded and an unstamped past holiday gets a record and a `STAMP` audit row on startup.

gabogg added this to the Historical passenger-flow backfill milestone

2026-10-03 08:47:07 +00:00

gabogg added the

ready-for-agent

bug

labels

2026-10-03 08:47:07 +00:00

gabogg referenced this issue

2026-10-03 08:47:27 +00:00

refactor(i18n): language-agnostic identifiers and payloads — i18n with English fallback, not a Spanish default #73

gabogg removed this from the Historical passenger-flow backfill milestone

2026-10-03 12:13:35 +00:00