I am using laravel queues for commenting on the facebook post. When ever i recieve data from facebook webhook, based on the recieved details i am commenting on the post. To
The accepted answer was a problem for me, but I also wound up on this question for 2 other similar problems which I solved, and maybe they will help other people that wind up here.
Other problem 1: job creation (constructor) works, but job handler does not fire - ever.
Other problem 2: job creation (constructor) works, but job handler does not fire - sometimes.
DB::beginTransaction
. Assuming I want the job to fire even during a transaction, I can do this:
/**
* Create a new job instance.
*
* @return void
*/
public function __construct($errorInfo)
{
$this->errorInfo = $errorInfo;
// Queues won't run the handlers during transactions
// so, detect the level, and if it is not 0, rollback to force job handling
if (\DB::transactionLevel() != 0) {
\DB::rollBack();
}
}
BUT DON'T DO THIS unless you want to fire your job and force rollback. My situation is unique in that my job sends emails on FATAL errors, so I want it to fire because I have an error breaking the process anyway (rollback going to happen and is unplanned due to uncaught error).
Here's a situation when you wouldn't want to do this:
You should structure your dispatch to happen AFTER you rollback or commit. I did not have that luxury for my job because it happens when I cannot predict (a FATAL error). But if you have control over it, like knowing your payment is successful, dispatch after you have committed, or exited all levels of transactions!
I am not sure of the behavior of triggering a job while in the transaction, and then rolling back or committing. It could be worked around if it didn't work properly by adding a delay, but that seems unreliable (guessing at how long to wait) unless it was a significant delay.