Re-enabling a paused recurring schedule fires immediately instead of resuming from 'now' #89

New Issue

2026-09-01T00:08:19-04:00

jared commented

2026-09-01 00:08:19 -04:00

Severity: Low

RecurringTicketModel::toggleActive() flips is_active without touching next_run_at. If a schedule is disabled while next_run_at is still in the future, then re-enabled after that date has passed, the next cron tick sees next_run_at <= NOW() and fires immediately — a single fire, not a catch-up flood (confirmed not to loop), but likely surprising to an admin who just re-enabled a "daily" schedule expecting it to wait until the next natural occurrence rather than create a ticket right away.

Fix: When re-enabling a schedule, recompute next_run_at from the current time (as if the schedule were being freshly created) rather than leaving a stale past timestamp that immediately qualifies as due.

**Severity:** Low `RecurringTicketModel::toggleActive()` flips `is_active` without touching `next_run_at`. If a schedule is disabled while `next_run_at` is still in the future, then re-enabled after that date has passed, the next cron tick sees `next_run_at <= NOW()` and fires immediately — a single fire, not a catch-up flood (confirmed not to loop), but likely surprising to an admin who just re-enabled a "daily" schedule expecting it to wait until the next natural occurrence rather than create a ticket right away. **Fix:** When re-enabling a schedule, recompute `next_run_at` from the current time (as if the schedule were being freshly created) rather than leaving a stale past timestamp that immediately qualifies as due.

jared added the priority/low ux labels 2026-09-08 10:15:49 -04:00

jared referenced this issue from a commit

2026-09-08 11:59:38 -04:00

Recompute next_run_at when re-enabling a paused recurring schedule (#89)

jared referenced this issue from a commit

2026-09-08 15:39:42 -04:00

Merge development into main: 15-issue triage + fix batch

Sign in to join this conversation.