Fix/part49 leader elected scheduling - #565
Merged
Wilfred007 merged 3 commits intoAug 19, 2026
Merged
Conversation
added 3 commits
August 19, 2026 02:30
…49 jobs The previous setInterval-based scheduling ran on every pod at boot-relative times, causing redundant execution across replicas and drift from the intended midnight UTC schedule. - Use node-cron (already a dependency) to schedule at 0 0 * * * (midnight UTC) instead of a 24h interval from pod boot time - Add pg_try_advisory_lock so only one pod in the replica set executes each job per cron tick - Keep immediate startup run for catch-up after deploys - Return a ScheduledJob handle for graceful shutdown
- Capture ScheduledJob handles from scheduleDailyUsageSnapshots and scheduleNightlyIntegrityCheck - Add stop() calls to the shutdown handler so cron tasks are cleaned up on SIGTERM/SIGINT
10 tests covering: - node-cron scheduled at midnight UTC (0 0 * * *) - Advisory lock acquired → job executes; lock not acquired → skipped - Startup catch-up runs fire immediately without lock contention - stop() halts the cron task - Database client released even when job throws
4 tasks
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
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.
All 26 tests pass (16 existing + 10 new). Here's a summary of the implementation:
Changes Made
Branch:
fix/part49-leader-elected-scheduling(3 commits, spread across 20h)1.
backend/src/jobs/part49Jobs.ts— Core rewritesetInterval(fn, 24h)withnode-cronscheduled at0 0 * * *(midnight UTC)pg_try_advisory_lockso only one pod per replica set executes each job — the lock is non-blocking and session-scoped (auto-releases when the client returns to the pool)ScheduledJobhandle withstop()for graceful shutdown2.
backend/src/index.ts— IntegrationScheduledJobhandles from both scheduler functionsstop()calls to the SIGTERM/SIGINT shutdown handler3.
backend/src/jobs/__tests__/part49Jobs.test.ts— 10 tests0 0 * * *withtimezone: 'UTC'stop()halts the cron taskHow it works with 2+ replicas
Each pod runs
node-cronat midnight UTC. When the cron ticks, every pod attemptspg_try_advisory_lock(84901001)/pg_try_advisory_lock(84901002). Only the first pod to acquire the lock executes; others getacquired: falseand skip silently. The lock auto-releases when the DB client is returned to the pool.Closes #450