ErrorsBackground work · rule
schedule.every_invalid
A schedule's every: says how often it runs in something other than a whole number of seconds, minutes, hours or days.
Area 12, Background work; not declinable; the next step is usually the agent's.
Why Jadpo refuses it
A schedule's runs fall on a grid of times, one every: apart, kept in
the schedule's state so that a restart or a deploy doesn't move them.
The grid counts in whole seconds, minutes, hours or days above zero:
30s, 15m, 1h or 1d. A gap in milliseconds, a fraction or zero has
no place on it, so Jadpo refuses it rather than round it to a different
interval.
What it looks like
main.jadpo:
action tidy() -> Unit {}/// Tidies up four times a second.schedule tidy_up { every: 250ms run: tidy()}
error every: 250ms can't be how often a schedule runs
--> main.jadpo:5:12
|5 | every: 250ms | ^^^^^ not seconds, minutes, hours or days
- reason
every:is a whole number of seconds, minutes, hours or days above zero (30s,15m,1h,1d), counted in UTC from when the application starts.- next
- Write a duration such as
every: 15m(agent) - rule
- schedule.
every_ invalid - help
- https://jadpo.
dev/docs/errors/schedule. every_ invalid
(agent) at the end of the next: line means your coding agent can make
the fix itself.
How to fix it
If the work can wait a second or more between runs, give every: a
whole number of seconds or more. In main.jadpo:
/// Tidies up once a minute.schedule tidy_up { every: 1m ...}
tidy now runs once a minute. Only one run happens at a time, and ticks
missed while a run is still going become one run, not a backlog.
Related
Markdown for agents: /docs/errors/schedule.every_invalid.md.Built from Jadpo main at aee2e8f.