Skip to content

fix: validate that step does not exceed field range#573

Open
nghiack7 wants to merge 12 commits into
robfig:v3from
nghiack7:fix/validate-step-range
Open

fix: validate that step does not exceed field range#573
nghiack7 wants to merge 12 commits into
robfig:v3from
nghiack7:fix/validate-step-range

Conversation

@nghiack7
Copy link
Copy Markdown

@nghiack7 nghiack7 commented May 9, 2026

Problem

ParseStandard("*/90 * * * *") silently accepts an invalid expression and schedules the job at minute 0 only (every hour), instead of returning an error.

A step value larger than the field's own range — e.g. 90 in the minutes field (range 0-59) — can never produce more than one trigger point. This hides a clear user mistake and leads to unexpected scheduling behaviour.

Reported in issue #543.

Root cause

getRange validates that start >= r.min, end <= r.max, start <= end, and step > 0, but never checks that step itself is within the field's range.

Fix

One additional check after the step is parsed:

if step > r.max-r.min {
    return 0, fmt.Errorf("step (%d) above maximum (%d): %s", step, r.max-r.min, expr)
}

This mirrors the style of the existing bounds checks and returns a clear, descriptive error.

Tests

Added two error-path cases to TestStandardSpecSchedule:

Expression Field Step Range max Expected
*/90 * * * * minute 90 59 error
* */30 * * * hour 30 23 error

All existing tests continue to pass.

yvanoers and others added 12 commits October 9, 2019 23:28
remove redundant asterisk in example
docs: remove redundant asterisk in example
Let cron depend on interface for parsers instead of fixed parser
Fix changing quartz scheduler site link for README
It was an error in channel scoping that was identified in pull robfig#263.

This adds a unit test to identify that issue and verify the fix.
A step value larger than the field's own range (e.g. */90 in minutes
where max=59) would silently accept the expression and schedule the job
only at the range minimum, hiding a likely user error.

Add a validation check after the step is parsed:

  if step > r.max-r.min {
      return 0, fmt.Errorf("step (%d) above maximum (%d): ...", ...)
  }

This mirrors the existing checks for start/end bounds and returns a
clear error rather than silently mis-scheduling.

Add two test cases to TestStandardSpecSchedule exercising the new
validation for the minute and hour fields.

Fixes robfig#543
@nghiack7
Copy link
Copy Markdown
Author

Friendly ping — this PR is ready for review. CI is clean ✅. Happy to make any changes requested.

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.

8 participants