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
feat(schedule-engine): stop persisting per-tick schedule state
Each scheduled-task tick previously issued 3 Prisma UPDATEs against
TaskSchedule.lastRunTriggeredAt, TaskScheduleInstance.lastScheduledTimestamp,
and TaskScheduleInstance.nextScheduledTimestamp. All three were pure
denormalization — every value can be derived without persisting.
Engine
- Drop the three per-tick prisma.update calls.
- Refactor registerNextTaskScheduleInstance to take a fromTimestamp arg
instead of reading instance.lastScheduledTimestamp from the DB.
- Add optional lastScheduleTime to the schedule worker payload so the
previous fire time travels forward via Redis. payload.lastTimestamp
is now sourced from the worker payload, not a DB column. First-ever
fires still report undefined so customer "first-run" sentinel
patterns keep working.
- For in-flight Redis jobs enqueued before this change (which lack
lastScheduleTime), fall back to instance.lastScheduledTimestamp once.
After those drain, the column is never read again.
Schema
- Mark the three columns @deprecated via triple-slash Prisma docstrings.
No migration — columns remain in place so revert is code-only. They
can be dropped in a follow-up once the rollout is stable.
Webapp
- ScheduleListPresenter derives the dashboard "Last run" cell from the
cron expression's previous slot, gated on schedule.createdAt so
brand-new schedules show "–". UI is best-effort; runs page is the
source of truth.
- API responses (api.v1.schedules.*) already compute nextRun from cron;
no public API change. lastTimestamp on the SDK payload retains
Date | undefined semantics — no SDK change either.
Tests
- scheduleEngine integration test asserts first-fire lastTimestamp is
undefined and the second fire carries the previous fire's timestamp
exactly.
- scheduleRecovery tests no longer assert against the deprecated
nextScheduledTimestamp column; presence of the worker job is the
source of truth.
References
- New references/scheduled-tasks project with declarative schedules at
multiple cadences plus three validators (first-fire-detector,
interval-validator, upcoming-validator) that throw on FAIL — used
for E2E-verifying the worker-payload flow.
Refs TRI-8891
Stop writing per-tick state (`lastScheduledTimestamp`, `nextScheduledTimestamp`, `lastRunTriggeredAt`) on `TaskSchedule` and `TaskScheduleInstance`. The schedule engine now carries the previous fire time forward via the worker queue payload, eliminating ~270K dead-tuple-driven autovacuums per year on these hot tables and the associated `IO:XactSync` mini-spikes on the writer. Customer-facing `payload.lastTimestamp` semantics are unchanged.
0 commit comments