Repository navigation
[go, js] refresh periodic schedules after commit - #1540
Merged
Merged
Conversation
bgentry
force-pushed
the
bg/periodic-keep-alive-after-commit
branch
3 times, most recently
from
October 25, 2026 05:56
25e6ad9 to
a468d0f
Compare
brandur
approved these changes
Oct 25, 2026
Every ten minutes, the leader refreshes the saved rows of its durable periodic jobs. Startup skips a row that has expired but is not reaped yet. The leader computes a new next run time and writes it in a transaction. If that transaction rolls back, keep-alive still refreshes the expired row. The row keeps its old next run time but looks current. The next leader loads it and enqueues every run since that time. Refresh a row only after its next run time is loaded at startup or committed. Track this with a flag on each registration. Clear the flag when a job is added and when leadership starts. Ignore a commit that finishes after its job is replaced or after leadership changes. Call keep-alive with an empty ID list when no job qualifies, so expired rows are still reaped. Add tests for a blocked startup, failed transactions, a later successful write, a restart, and a job replaced during commit. A Go test runs a batch through a real transaction to show that a rollback leaves the job ineligible.
bgentry
force-pushed
the
bg/periodic-keep-alive-after-commit
branch
from
October 25, 2026 21:40
0e6410f to
91e31b3
Compare
bgentry
marked this pull request as ready for review
October 25, 2026 21:45
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.
Every ten minutes, the leader refreshes the saved rows of its durable periodic jobs. At startup, it skips a row that has expired but is not reaped yet. It computes a new next run time and writes it in a transaction. If that transaction rolls back, keep-alive still refreshes the expired row. The row keeps its old next run time but looks current. The next leader loads it and enqueues every run since that time.
This change refreshes a row only after its next run time is loaded at startup or committed. Each registration carries a flag for this. The flag clears when a job is added and when leadership starts. A commit that finishes after its job is replaced, or after leadership changes, does not set it. When no job qualifies, keep-alive still runs with an empty ID list, so expired rows are still reaped.
Go and JS get the same fix and equivalent tests. The tests cover a blocked startup, failed begin, upsert and commit, a later successful write, a restart, and a job replaced during commit. A Go test also runs a batch through a real transaction to show that a rollback leaves the job ineligible.