Skip to content

fix(scheduler): stop bumping updated_at in run-time writes (#420) - #425

Merged
vybe merged 3 commits into
mainfrom
feature/420-scheduler-sync-updated-at
Apr 20, 2026
Merged

fix(scheduler): stop bumping updated_at in run-time writes (#420)#425
vybe merged 3 commits into
mainfrom
feature/420-scheduler-sync-updated-at

Conversation

@vybe

@vybe vybe commented Apr 20, 2026

Copy link
Copy Markdown
Contributor

Summary

  • update_schedule_run_times was bumping updated_at alongside the run-time columns. The scheduler's sync loop watches updated_at to detect config edits, so every tick saw its own write from the previous _add_job and re-registered all N schedules once per minute — ~7k "Added job" log lines per 8h for 13 schedules, growing linearly with fleet size.
  • Fix: updated_at is now only bumped on legitimate config changes (update_schedule, set_schedule_enabled). Runtime writes leave it alone. APScheduler idempotency (replace_existing=True) was already masking the scheduling impact, so no execution behavior changes — just DB/log churn.

Changes

  • src/scheduler/database.pyupdate_schedule_run_times, update_process_schedule_run_times no longer touch updated_at.
  • src/backend/db/schedules.py — same for the backend's copy of update_schedule_run_times.
  • tests/scheduler_tests/test_sync_loop.py — new regression test file (4 tests).

Test Plan

  • pytest scheduler_tests/test_sync_loop.py -v — 4/4 pass
  • pytest scheduler_tests/ — 149/149 pass
  • pytest test_schedules.py — 23/23 pass
  • Deploy to one instance; docker logs trinity-scheduler --since 5m | grep -c \"Added schedule job\" should report 0 (was ~5×N).

Notes

Closes #420

Generated with Claude Code

vybe and others added 3 commits April 20, 2026 12:25
`update_schedule_run_times` was setting `updated_at = now()` alongside
`last_run_at` / `next_run_at`. The scheduler's periodic sync loop watches
`updated_at` to detect config edits — so every sync tick saw its own write
from the previous `_add_job`, flagged every schedule as "updated," and
re-registered all N jobs once per minute. Logs grew linearly with fleet
size (~7k "Added job" lines per 8h for 13 schedules).

Fix: `updated_at` now tracks config changes only. User-initiated edits
(`update_schedule`, `set_schedule_enabled`) still bump it and still trigger
the sync branch correctly. Runtime writes (`last_run_at` / `next_run_at`)
no longer do.

Applied to three call sites:
- src/scheduler/database.py: update_schedule_run_times,
  update_process_schedule_run_times
- src/backend/db/schedules.py: update_schedule_run_times

Added regression tests in tests/scheduler_tests/test_sync_loop.py:
- update_run_times does not mutate updated_at (agent + process)
- three consecutive sync ticks with no DB edits produce zero add_job calls
- a legitimate cron edit still triggers the sync update branch

Closes #420

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add the "run-time writes must not bump updated_at" invariant to Flow 6 in
scheduler-service.md and flag it in the update_schedule_run_times /
update_process_schedule_run_times entries. This is the contract the sync
loop depends on — future maintainers touching these methods need to know.

Also bump the stale line ranges in those two method entries and add an
entry for #420 to the feature-flows index.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add test_sync_loop.py to the Scheduler Tests category, a 2026-04-20 entry
to Recent Test Additions, and bump unit-test totals by the 4 new tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: scheduler re-registers every schedule from DB once per minute

1 participant