1
votes

I am curious how can I know when a queued job completed successfully to potentially notify the relevant user, if they choose to receive notifications.

Specifically I am working with a Laravel Excel export with the ShouldQueue trait. It includes a handy method to handle failed jobs, so I can notify the user on failure if needed (see https://docs.laravel-excel.com/3.1/exports/queued.html#handling-failures-in-queued-exports). I'm assuming there isn't some success method that is either undocumented, or documented where I am not finding it, so....

Is there a way to use Laravel's queuing system to detect when a job is finished? Even if I don't truly know the status (success or fail) and I only know the job is done, I could check for the existence of the export file to confirm it was successful to trigger notification.

Thanks.

2

2 Answers

0
votes

You can manage this by adding the below code to your AppServiceProvider.php

public function boot()
{
Queue::before(function (JobProcessing $event) {
// $event->connectionName
// $event->job
// $event->job->payload()
});

Queue::after(function (JobProcessed $event) {
// $event->connectionName
// $event->job
// $event->job->payload()
});
}

For More details, you can refer https://laravel.com/docs/8.x/queues

0
votes

So while @Yudiz Solutions answer is correct in general. I found a better way that is specific to a queued Laravel Excel export job like I mentioned I have.

I just found this in the docs https://docs.laravel-excel.com/3.1/exports/queued.html#appending-jobs

So while there isn't an explicit success method like there is for failure I can chain on a second job that is dependent on the first and have the second job handle the notification.

Funny enough I have probably scrolled by this section in the docs so many times without realizing that it was either there or that it was the answer to my need of notifying the user on success.

Even take away the specific context of this being a Laravel Excel export job I think chaining a success notification like this would still be possible and is probably a better way to go for any job where it is specific to a given job.

@Yudiz Solutions answer is better suited for something that should run after every (or at least most) jobs generally.