Closed dd32 closed 4 years ago
recurring jobs set status = 'waiting'
after successful runs, so it runs again.
I'm unsure if the failure is the runner or the plugin (or both). It would make sense that the plugin would only show jobs listed as status = 'waiting'
, which will cause wp_next_scheduled()
not to show a date for failed jobs. It would also make sense for the Runner not to set the job as failed for a recurring job.
Changing the plugin to only return waiting
jobs would mean that if a recurring job failed, there'd be multiple entries in the cavalcade_jobs
table for that blog/hook - I'm unsure if that's a problem though.
In this case, I manually reset the
status
field for the jobs in question towaiting
and it continued on it's way.
When doing that then for some reasons the job is running every second for a while. Is that because it's re-running all the jobs which didn't run before?
When doing that then for some reasons the job is running every second for a while. Is that because it's re-running all the jobs which didn't run before?
Yes, unless you update the nextrun
field too. for most jobs it doesn't matter, but that job which was running every minute had a fair bit of iterations to catch up on (as the next run is calculated by nextrun = nextrun + schedule
)
Correct; if you change it back to waiting
, Cavalcade will continue running it normally, and it doesn't skip cycles. If you have a task that runs every minute, and it stops for five minutes, it will have to run 5 times before it catches back up.
I think the intention of #27 was to fix this, which I'm assuming it did as it hasn't been an issue on WordPress.org in years.
Ran into an interesting scenario today where a daily recurring job failed last week and it wasn't queued again / re-run.
In the
cavalcade_jobs
table, thestatus
was'failed'
wp_next_scheduled( $job )
returned the date for the next time after that failed run when it should have run (The plugin queries for jobs which arestatus != 'complete'
to return in the cron array)status = 'waiting'
.This ended up in a situation where WordPress thought the job was queued and Cavalcade didn't attempt to run it.
In this case, I manually reset the
status
field for the jobs in question towaiting
and it continued on it's way.