Possible wrong instance of JobProcessing event is fired.

[halaei]

Laravel 5.3
SyncQueue::raiseAfterJobEvent() assumes that the connection name is 'sync' when creating a Events\JobProcessing instance. But that is not a true assumption. At that point, we only know that the queue driver is 'sync' and know nothing about the connection name.

[GrahamCampbell]

Thanks for the report. How do you suggest we fix this please? :)

[halaei]

I think it can be fixed by adding a connenctionName property to the constructor. However, I am thinking maybe it is better to remove the whole event firing code in SyncQueue. My guess is nobody uses those events, at least for jobs pushed to sync queue. Removing events from SyncQueue will also make it easy to register listeners for #16739

[themsaid]

A change was introduced in this area to fix an issue with logging failed sync requests that run from within a parent job, take a look here: #16681

I'm not sure if there's a use case where you'll need to have multiple sync drivers, that's why we use sync as a name for the connection if the driver is sync.

[halaei]

Thanks @themsaid for the info. I agree that this is not a big deal. Here is a listener for JobProcessing event that makes me happy for now :)

class RefreshDBConnections
{
    /**
     * @var ExceptionHandler
     */
    protected $exceptions;

    public function __construct(ExceptionHandler $exceptions)
    {
        $this->exceptions = $exceptions;
    }

    public function handle(JobProcessing $event)
    {
        if ($event->connectionName != 'sync') {
            try {
                while (\DB::transactionLevel() > 0) {
                    \DB::rollBack();
                }
            } catch (Exception $e) {
                \DB::reconnect();
                $this->exceptions->report($e);
            }
        }
    }
}

[halaei]

illuminate.queue.looping event is much better!