fix(workflow): catch up missed cron fires - #7506
Conversation
Signed-off-by: Forge <forge@bluroot.co>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🔐 Codex Security Review
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0d05ec6e90
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| -- start at deployment time so rollout never replays historical schedules. | ||
| SET LOCAL lock_timeout = '5s'; | ||
|
|
||
| CREATE TABLE workflow_schedule_cursors ( |
There was a problem hiding this comment.
Mirror the cursor into the desired-state schema
This defines the cursor relation only in the incremental migration; a repo-wide search confirms that schema/schema.sql contains neither workflow_schedule_cursors nor its reset trigger. Fresh databases created through the repository's pgschema apply path therefore lack this relation, so every cron tick fails in get_or_seed_workflow_schedule_cursor, and community-deletion catalog validation also expects a table that is absent. Add the table, trigger function, trigger, and write fence to the desired-state schema.
AGENTS.md reference: AGENTS.md:L557-L557
Useful? React with 👍 / 👎.
| limit = MAX_SCHEDULE_FIRES_PER_TICK, | ||
| "Cron tick: global schedule fire budget exhausted" | ||
| ); | ||
| break; |
There was a problem hiding this comment.
Make the global fire budget fair across workflows
When more than 100 schedule instants are due per minute, this fixed-order break permanently starves later workflows: list_all_enabled_workflows orders by created_at ASC, the first 100 minutely workflows consume the entire budget, and those same workflows each become due again before the next tick, so workflow 101 is never visited and its backlog only grows. The cap needs fair rotation or pagination across workflows rather than restarting from the oldest row on every tick.
Useful? React with 👍 / 👎.
Summary
Related issue
Migration
Adds
migrations/0045_workflow_schedule_cursors.sql. The owner approved this migration for deployment on 2026-09-08. It creates the scheduler cursor table and its cleanup trigger; no existing application data is rewritten.Testing
buzz-workflowunit tests passed0d05ec6e90087b88fea403aa512779908adf8e80