Craft CMS Stack Exchange is a question and answer site for administrators, end users, developers and designers for Craft CMS. It only takes a minute to sign up.
Sign up to join this community
I have a queue that runs from a cron tab and I'd like to know immediately if it ever fails. Is there an event that fires or any other kind of way to hook into the queue behavior in a module when it runs/completes/fails a job?
This is specifically a Feed Me queue that I'm talking about, but I'm looking for any kind of help with catching completed/failed queue jobs even if it's not Feed Me specific.
I don't believe there are any events triggered by queue jobs that you can listen for. Feed Me does have an event called afterProcessFeed (more on that here) that's triggered after a feed is processed (i.e. all feed items are completed), but that won't be triggered if the Feed Me queue job fails for some reason.
If you're worried about a queue job timing out and failing, there are techniques to handle queue jobs running out of memory or execution time and failing. PutYourLightsOn's excellent Campaign plugin takes pains to handle this by allocating as much memory as possible and monitoring both memory and timeout values during the queue job. If the values are exceeded (i.e. the job is about to fail), a new job is scheduled to take over after a delay.
You can check out how this is done in the Campaign SendoutJob class here. I must credit PYLO's Ben Croker for pointing me in the direction of his code when I was asking similar questions about handling queue job failures.
Something like this might potentially work to catch queue job errors, regardless of what it is. Potential actions for the EVENT_AFTER_ERROR could be releasing and requeuing the job that failed.
Event::on(Queue::class,
Queue::EVENT_AFTER_ERROR,
static function(ExecEvent $event) {
$queue = Craft::$app->getQueue();
$queue->release($event->id);
$queue->delay(30)->push($event->job);
}
);
Credit to Oliver Stark from Fortrabbit for the concept: https://gist.github.com/ostark/e0444e3e231cc937a31908b651e845b3.
This came out of investigating queue job handling when certain updates or application config changes are made which causes our non-stop queue/listen worker to restart which could occur during a running queue job and cause it to error due to the SIGTERM 15 signal. You might not need the EVENT_WORKER_START event as this is more specific to the environment we have, but EVENT_AFTER_ERROR should give you access to hook into queue jobs that raised an error and do whatever handling you might want.
