Fix scheduled workflows executing multiple times (#506)

[DevDesai444]

Summary

• make schedule advancement a due-only claim so only one worker can claim a due schedule
• add the same claim semantics to memory and file datastores for consistency
• add regression tests to verify a second claim on the same due schedule fails

Problem

Scheduled workflows could run twice in quick succession when concurrent scheduler workers picked up the same due schedule.

Root cause

updateScheduleNextRun updated by schedule id without checking that the schedule was still due at update time.

Fix

• Postgres: conditional update with enabled = true AND next_run_at <= CURRENT_TIMESTAMP
• Memory/File: guard update behind enabled+due checks
• Tests: added one-claim-only tests in all datastore suites

Fixes #506
Issue: #506

---

Summary by cubic

Prevents duplicate scheduled workflow runs by making schedule advancement a single-claim operation on due schedules. Aligns due-schedule selection and claim checks to the same TIMESTAMPTZ semantics to avoid timezone mismatches.

• Bug Fixes
  • Postgres: claim update only when enabled = true and next_run_at <= CURRENT_TIMESTAMP; also sets updated_at.
  • Postgres: listDueToolSchedules now compares TIMESTAMPTZ to CURRENT_TIMESTAMP directly (no timezone coercion) to match claim logic.
  • Memory/File: guard updates behind enabled + due checks.
  • Tests: add one-claim-only tests across all datastores to prevent double execution.

^{Written for commit b82252c. Summary will update on new commits.}

[CLAassistant]

All committers have signed the CLA.

[cubic-dev-ai]

1 issue found across 7 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/core/datastore/postgres.ts">

<violation number="1" location="packages/core/datastore/postgres.ts:1208">
P2: listDueToolSchedules uses `CURRENT_TIMESTAMP at time zone 'utc'` (timestamp without tz) while the new `updateScheduleNextRun` guard uses `CURRENT_TIMESTAMP` (timestamptz). In Postgres, comparing a timestamp without tz to a timestamptz assumes the session time zone, so if the DB isn’t set to UTC these two “now” values diverge. That can make listDue return schedules that aren’t actually due (or miss due ones), leading to failed claims or delays with the new guard.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}