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
Fix schedule reload: scheduler now syncs from DB directly (v2.6.63)
Schedule create/update/delete dispatched reload_schedules_task via Celery,
but prefork workers execute tasks in pool children while APScheduler runs
only in the scheduler-lock-holding main process. The reload always landed
in a child and was skipped, so schedule changes never reached the running
scheduler without a container restart.
The scheduler process now re-syncs its jobs from the database every 60
seconds, gated on a fingerprint of schedule definitions so jobs are only
rebuilt on actual change. next_run is computed at schedule creation so the
UI shows the upcoming fire before the first run.
Copy file name to clipboardExpand all lines: CHANGELOG.MD
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,12 @@ All notable changes to this project will be documented in this file.
5
5
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
6
6
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0).
7
7
8
+
## [2.6.63] - 2026-07-09
9
+
10
+
### Fixed
11
+
12
+
-**Created or edited schedules now take effect within a minute instead of requiring a container restart.** Schedule CRUD dispatched `reload_schedules_task` through Celery, but prefork workers execute tasks in pool children while APScheduler runs only in the scheduler-lock-holding main process - the reload always landed in a child, logged "Scheduler not running in this worker", and was skipped, so no schedule change since the mechanism was added ever reached the running scheduler without a restart (verified live: a freshly created `file_changes` schedule never fired at its cron time). The scheduler process now re-syncs its jobs directly from the database every 60 seconds, gated on a fingerprint of the schedule definitions so jobs are only rebuilt when something actually changed. New schedules also get `next_run` computed at creation so the UI shows the upcoming fire immediately instead of after the first run.
0 commit comments