Bus::batch()->finally() callbacks not called after catch() callbacks?

[tobz-nz]

Hi, is it just me or does the finally callback on bus::batch(...)->finally(...) not get called when a job fails?
The catch(...) callbacks are, but not the finally - which should be called both when exceptions are caught and when all jobs run successfully... shouldn't it?

is this a bug, or do I just not understand something?

Example:

Bus::batch([
    new JobThatThrowsAnException
]->catch(function() {
    dump('This runs');
})->finally(function () {
    dump('this does not run, but it should');
}););

[dyaskur]

->catch run when the job catches an error/exception, and if you catch error you will not run ->finally. If your job doesnt catch an error/exception , ->catch will not run and goto ->finally

[tobz-nz]

Yes, that is what happens, but I'd expect finally() run as well as the exception catcher (if an exception is caught).
Bottom line, finally should always run.

This is how a normal try {} catch() {} finally {} block works.

Also, if the finally callback was only supposed to run on successfully completed batch, what's the point of the then() callbacks? They already do that job.

[bhulsman]

I agree, I also expected finally to always run after the batch is completed, with or without errors.

[ISMHiddeSchuurman]

I'm having the same issue. When I look at Telescope, there are 39 pending jobs left:

But these 39 jobs are failed, so the batch should be finished. But instead, it keeps hanging on 'pending'.
The finally() callback is never called.

[dwleh]

Should this be a feature request? Seems like the naming of the function is misleading since it doesn't stick with the widely known convention of the native try {} catch() {} finally {}.

As our team was recently bitten quite severely by this "misunderstanding" my preference would of course to make finally always run, regardless of what happens before.

[bhulsman]

I agree! Or add always, but I'm not sure what finally really is for then.

[mylemans]

Should this be a feature request? Seems like the naming of the function is misleading since it doesn't stick with the widely known convention of the native try {} catch() {} finally {}.

As our team was recently bitten quite severely by this "misunderstanding" my preference would of course to make finally always run, regardless of what happens before.

I'd say it is more of a bug then in either the code or the docs:

Docs have this in the 'finally' callback
// The batch has finished executing...

And there is indeed a 'then' that indicates its invoked when no jobs failed.

[izdanevych]

Any chance this will ever be fixed?

[maxheckel]

I would also expect finally to return when the batch completes regardless of failures. This is useful for my project to be able to know when a batch is done and trigger an event to the UI to say it has finished running (with errors or without)

[oliverbj]

Will this ever be fixed? :)

[prattcmp]

+1, any fix for this? Very important for critical batched workloads.

[HeinHanekom]

+1 Hard to use this to it's full potential if we cannot rely on finally being called.

[alexandrecruz]

To this day, this issue is still confusing and differs from what the expectation is for a finally block.

[TWithers]

The fix for this is fairly simple, but I don't know if it is a fix or not. Inside CallQueuedHandler you just need to check if the job had other jobs chained to it, and then decrement the pending jobs in the queue before failing the original job. This will ensure the finally callback is triggered.

protected function ensureFailedBatchJobIsRecorded(string $uuid, $command, $e)
    {
        if (! in_array(Batchable::class, class_uses_recursive($command))) {
            return;
        }

        if ($batch = $command->batch()) {
            foreach ($command->chained ?? [] as $index => $chained) {
                $batch->decrementPendingJobs($uuid.'-'.$index);
            }
            $batch->recordFailedJob($uuid, $e);
        }
    }

The only reason I am not wanting to spend time on making a PR is that it is likely a breaking change since the current mode of operation is seen as the desired effect, and not a bug: #39243 (comment)

I also don't know if this is the ideal way to handle the implementation. There is not a way to "fail" the remaining jobs in the chain because they were never dispatched to the queue to begin with, and it doesn't make sense to record a failed job when it hasn't been attempted.

Another way would be to modify Batch::add() and change it so it only adds a single job for chains, add a public function to increment the total jobs, and in the CallQueuedHandler::ensureNextJobInChainIsDispatched() add in something like:

if ($batch = $command->batch()) {
    $batch->incrementTotalJobs(1);
}

This way, however, doesn't play very nice with the progress() callback as it is continually incrementing the total jobs it needs to do.

[erycson]

Today I had the same problem with this task, but after using the code below, I was able to make finally() be called:

<?php

public function handle()
{
    try {
        ... Your code here, which throws an error
    } catch (catch (Exception $e) {
        $this->fail($e);
    }
}

May this help someone in the future as it helped me today.