You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d42004b
Browse filesBrowse the repository at this point in the historyBrowse files
sys_report_schedule has long carried `cron_expression` and `timezone`
fields, but ReportService only ever advanced next_run_at by
`interval_minutes` — both fields were stored and ignored. Scheduling now
computes next_run_at from the cron expression (when present) in the
schedule's timezone via croner — the same library the job scheduler uses —
so "every weekday 09:00 local" is expressible. interval_minutes remains the
fallback.
- cron_expression wins over interval_minutes when set (the field's
documented contract); evaluated in `timezone` (default UTC).
- scheduleReport validates the cron eagerly → VALIDATION_FAILED on bad
input, rather than silently falling back at sweep time. A cron that
becomes unschedulable later is logged and falls back to interval; it
never throws into the dispatch sweep.
- Shared nextRunAt() helper drives both initial schedule and advance.
DB-polling dispatch model unchanged; only the next-run computation is
cron-aware. Self-contained slice of ADR-0053 Phase 2 — report schedules
run under a system context, so the tz source is the schedule's own field,
independent of the reference-timezone resolver.
Tests: cron drives/overrides interval; honors timezone (09:00 ET = 14:00Z);
invalid cron rejected; dispatchDue advances to next cron occurrence. Full
plugin-reports suite green (29). Closes#1983.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`sys_report_schedule` has long carried `cron_expression` and `timezone` fields, but `ReportService` only ever advanced `next_run_at` by `interval_minutes` — both fields were stored and ignored. Scheduling now computes `next_run_at` from the cron expression (when present) in the schedule's timezone via `croner` — the same library the job scheduler uses — so "every weekday at 09:00 local" is expressible. `interval_minutes` remains the fallback.
8
+
9
+
-`cron_expression` wins over `interval_minutes` when set (the field's documented contract).
10
+
- Evaluated in `timezone` (default `UTC`).
11
+
-`scheduleReport` validates the cron expression eagerly and rejects an invalid one with `VALIDATION_FAILED`, rather than silently falling back at sweep time. A cron that becomes unschedulable later is logged and falls back to the interval — it never throws into the dispatch sweep.
12
+
13
+
The DB-polling dispatch model is unchanged; only the next-run computation is cron-aware. Part of ADR-0053 Phase 2 (#1983) but self-contained — report schedules run under a system context, so the timezone source is the schedule's own field, independent of the reference-timezone resolver.
0 commit comments