Skip to content

fix(cron): reject schedule numbers that stop early - #111

Draft
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/high-severity-issues-e5bc
Draft

cursor[bot] wants to merge 1 commit into
mainfrom
cursor/high-severity-issues-e5bc

Conversation

@cursor

@cursor cursor Bot commented Oct 7, 2026

Copy link
Copy Markdown

Bug and impact

cron_parse_next_run treated a numeric prefix as a full schedule value.

  • at:2026-10-08 (or at:tomorrow) stored next_run as 2026 or 0. That timestamp is already due, so the next cron poll ran the one-shot immediately and cron_ack_delivery deleted it. The future reminder was lost.
  • cron:0 9 * * 1,3,5 and cron:0 9 1,15 * * were accepted and matched only the first number, so the job ran on the wrong days.
  • interval:60abc was accepted as 60 seconds.

Dashboard POST /api/cron and the cron tool both call this parser.

Root cause

strtol / strtoll stop at the first non-digit. The parser checked that conversion started, then ignored the remainder.

Fix

Require the entire numeric token to be consumed for at:, interval:, and cron fields (*, a single number, or N-M still work). A partial value is rejected and next_run is left unchanged, so the job is not created.

Validation

make test_cron failed on at:2026-10-08 before the parser change and passes after it, including the existing schedule cases.

Open in Web聽View Automation聽

strtol and strtoll accepted a numeric prefix, so at:2026-10-08 stored
next_run 2026. That one-shot was already due, ran on the next poll, and
ack deleted it. Comma lists such as 1,3,5 matched only the first value
and still scheduled.

Co-authored-by: esadrianno <esadrianno@gmail.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant