fix(scheduler): never persist 0001-01-01 as next_run_at (Closes #1)#8
Merged
Conversation
After AddJob registers a cron task with gocron, calling job.NextRun() immediately can return a zero time.Time — the job hasn't fired yet, so gocron has no scheduled run to report. The engine was writing that zero straight to schedulers.next_run_at, which Postgres stores as 0001-01-01 00:00:00. The web UI compares next_run_at to Date.now() and renders "Overdue" for every freshly-seeded scheduler, even though the cron expression is valid and the engine will fire it on time. Add a fallback path: when gocron returns zero, parse the cron expression ourselves with robfig/cron (already a dependency) and compute the next firing in the scheduler's configured timezone. Skip the DB write if both sources fail to produce a real instant — better to leave the column untouched than to write 0001-01-01. The same pattern applies after a fire completes; updated both call sites through a new resolveNextRun helper so they stay in sync. Tests cover the fallback computation directly: hourly cadence advances, Asia/Bangkok timezone is honored, an unrecognised tz falls back to UTC, and bogus cron strings return a parse error.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Engine was writing
next_run_at = 0001-01-01 00:00:00to the DB afterregistering a cron job with gocron —
job.NextRun()returns a zerotime.Timebefore the first firing, and we passed that straight toUPDATE schedulers SET next_run_at = $1. The UI then rendered "Overdue"for every freshly-seeded scheduler.
Fix: fall back to parsing the cron ourselves (
robfig/cron, already adep) when gocron returns zero, applying the scheduler's
timezone. Skipthe DB write entirely if both sources fail.
Closes #1.
Changes
internal/scheduler/manager.gocomputeNextRun(schedule, timezone)helper usingrobfig/cronresolveNextRun(s, job)— gocron first, hand-computed fallback, zero lastAddJoband the post-firing update path use the new helper and skip the write on zerointernal/scheduler/manager_test.go— 4 new tests for the fallback (hourly cadence, Asia/Bangkok timezone, bad-tz fallback to UTC, bad cron error)Test plan
go test ./internal/scheduler/...passes (existing + 4 new tests)go vet ./...cleango build ./...cleannext_run_atis a real future timestamp (not0001-01-01)/p/<id>/schedulers— every active row shows "next In Xm/Xh/Xd" instead of "Overdue"🤖 Generated with Claude Code