Scheduler core with period keys and catch-up (Feature 20) #171

2026-10-09T18:25:02-04:00

2026-10-09 18:25:02 -04:00

Maestro task f7024755-c3d3-46f3-b798-e242ad676c1e. internal/scheduler: registered schedules with household settings, exactly-once period claims via schedule_runs, boot catch-up within 24 h, DST/ISO-week-53 correctness and a settings subscription. No concrete schedules yet. See the developer report on the PR.

orchestrator-agent added 1 commit 2026-10-09 18:25:03 -04:00

Add the scheduler core with period keys and catch-up

CI / ci (pull_request) Successful in 8m2s

Details

CI / ci (push) Successful in 8m22s

Details

b46192a43d

internal/scheduler runs registered schedules (a name, a daily or weekly
rule read from the household settings, and a run function) in the
household zone with an injectable clock. Each fire time's period is
claimed by inserting schedule_runs(schedule, period_key) with ON
CONFLICT DO NOTHING, so a period runs at most once across restarts and
instances. At boot only each schedule's most recent fire time is
considered: within 24 h it runs once, older it is claimed as missed so
it never runs later. Settings changes move the next fire time through
SettingsService.Subscribe. DST follows household.LocalTime. The server
starts it with the worker context and waits for it before closing the
database; the concrete schedules come in later Feature 20 tasks.

Maestro task f7024755-c3d3-46f3-b798-e242ad676c1e.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review_agent requested changes

2026-10-09 18:29:44 -04:00

Dismissed

review_agent left a comment

Independent Codex gpt-6-sol review: CHANGES_REQUIRED for this exact commit.

overseer added 1 commit 2026-10-09 18:41:12 -04:00

Apply settings changes at their save time and retry failed claims

CI / ci (push) Successful in 7m57s

Details

CI / ci (pull_request) Successful in 7m33s

Details

6f7e1d2342

A settings change is now queued with the instant it was saved, and the
loop handles fire times up to that instant under the old rule and later
ones under the new, so a fire time the change made due is not skipped
when the scheduler gets to the change late (SCHED-01).

A failed claim no longer advances the loop past its period: the pass is
repeated every ClaimRetry until the claim succeeds, and periods already
claimed in that pass are skipped by the claim, so each runs once
(SCHED-02).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review_agent requested changes

2026-10-09 18:47:27 -04:00

Dismissed

review_agent left a comment

Independent Codex gpt-6-sol review: CHANGES_REQUIRED for this exact commit.

overseer added 1 commit 2026-10-09 19:02:11 -04:00

Retry a failed claim for its own period before later fire times

CI / ci (push) Successful in 7m29s

Details

CI / ci (pull_request) Successful in 7m44s

Details

bcd875c11f

A failed claim was retried by recomputing the most recent fire time from
the new now, so a daily claim that failed on 7 October and recovered after
the 8 October fire claimed only 8 October: the 7 October period was never
claimed nor recorded as missed. The scheduler now keeps each failed
claim's fire time and claims that same period every ClaimRetry until it
succeeds, applies the catch-up rule to it then, and only afterwards
handles later fire times and settings changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

review_agent approved these changes

2026-10-09 19:09:37 -04:00

review_agent left a comment

Independent Codex gpt-6-sol review: APPROVED for this exact commit.

approver_agent merged commit e5c13732d6 into feature/46305394-a839-4259-a639-85c99eca46af-scheduler-and-weekly-automation

2026-10-09 19:35:48 -04:00

dev_agent referenced this pull request

2026-10-10 17:40:20 -04:00

Feature 20: Scheduler and Weekly Automation #182

Sign in to join this conversation.