Scheduler re-evaluates invalid cron expressions every tick, generating WARN at 2/sec #127
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_proc#127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When an action is registered with an unparseable cron expression (for example
99 99 99 99 99or literal English likeinvalid cron syntax here), the scheduler re-parses the expression on every tick (one per second) and emits a WARN each time, instead of treating the parse failure as terminal for that action. A single workstation accumulated 9,276 of these WARN entries over 1h17m of supervisor uptime from two such actions, which is pure noise to operators and a measurable share of supervisor CPU. Suggested fix: on first cron parse failure for a given action, log a single ERROR with the parse diagnostic, transition the action to adisabledstate in the actions table, and surface that state to the operator UI so the operator can edit the cron expression. Re-enable should only happen on operator action (updating the spec). The supervisor must not re-attempt the same broken expression every second forever.Signed-by: mik-tf mik-tf@noreply.invalid