schedules.lease_held
A schedule was run by hand while another run of it still holds its lease, so it wasn't run again.
Area 14, Tools; not declinable; the next step is usually the human's.
Why Jadpo refuses it
A schedule runs once at a time. A run takes the schedule's lease, a
claim with an end time on its state row, and keeps it until it ends.
jadpo schedules run takes the same lease, so it can't start a run
beside one still going, whichever instance of the app started that one.
Jadpo won't take the lease from the run that holds it, or run beside it: two runs of one schedule could each do its work, such as sending the digest twice. Whether to wait for it, or find out why it is taking so long, is yours to decide.
What it looks like
A project whose morning_digest runs send_digest once a day:
domains/news/schedules/morning_digest.jadpo:
use news/actions { send_digest }/// Sends the digest every morning.schedule morning_digest { every: 1d run: send_digest()}
No run here lasts long enough to catch it holding the lease, so this
output is copied rather than checked. It is jadpo schedules run on a
Mac, against jadpo dev's database, with a run of morning_digest that
started a minute before written into its tables by hand, as a run still
going leaves them:
jadpo schedules run morning_digest error morning_digest is already running
- reason
- A run that started at 21:13:00 holds its lease until 21:29:00, and only one run of a schedule happens at a time.
- next
- Wait for it to end, or see it with
jadpo why morning_digest(human) - rule
- schedules.
lease_ held - help
- https://jadpo.
dev/docs/errors/schedules. lease_ held
(human) at the end of the next: line tells your coding agent to stop
and ask you which fix you want, because the choice is yours to make: it
decides whether a second run of morning_digest happens.
How to fix it
The question is whether the run holding the lease is still working.
If it is still working, wait for it to end, and see how it went:
jadpo why morning_digestjadpo why shows the run while it is going, and its outcome once it
has ended; the schedule is then free to run again.
If its worker was lost, as when the app stopped during the run, wait for the lease to end, then run it again:
jadpo schedules run morning_digestThe next tick after the lease ends records the lost run as
lease_expired, and the run by hand goes ahead.
Related
Markdown for agents: /docs/errors/schedules.lease_held.md.Built from Jadpo main at aee2e8f.