You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using the queue config option 'after_commit' set to true, in order that all jobs that are dispatched within transactions, are pushed after the transaction commits.
We use horizon tags, and saw lately that the tags did not match up with what the actual job.
After some digging we found out that when having after_commit set to true, the tags that are generated are taken from the previous job that was pushed to queue, not the actual one that i being pushed.
We followed this down the rabbits hole to RedisQueue.php in the method pushRaw. When after_commit is set to true, $this->lastPushed that is used to 'prepare' the job (extract tags etc) contains the last job that was pushed instead of the actual one that is being prepared.
Steps To Reproduce:
Create 2 different jobs with each either manually tagging or passing a model as a constructor value
If you set a breakpoint in RedisQueue.php on the first line of pushRaw you will see that in both cases $this->lastPushed is equals to the JobB job instance, and therefore is passed along to the prepare method which will falsely determine the tags (and other things)
The tags that are determined (before being pushed to queue, and put into payload) will be those of JobB also for JobA.
I have tried to identify where this issue is coming from but can currently can not pinpoint it exactly nor propose a solution.
Fantastic, thank you both @driesvints and @themsaid for the swift fixing! I'll check the fix out in a couple of hours to confirm our logs are showing the correct tags.
Description:
We are using the queue config option 'after_commit' set to true, in order that all jobs that are dispatched within transactions, are pushed after the transaction commits.
We use horizon tags, and saw lately that the tags did not match up with what the actual job.
After some digging we found out that when having after_commit set to true, the tags that are generated are taken from the previous job that was pushed to queue, not the actual one that i being pushed.
We followed this down the rabbits hole to
RedisQueue.php
in the methodpushRaw
. When after_commit is set to true,$this->lastPushed
that is used to 'prepare' the job (extract tags etc) contains the last job that was pushed instead of the actual one that is being prepared.Steps To Reproduce:
If you set a breakpoint in
RedisQueue.php
on the first line ofpushRaw
you will see that in both cases$this->lastPushed
is equals to the JobB job instance, and therefore is passed along to theprepare
method which will falsely determine the tags (and other things)The tags that are determined (before being pushed to queue, and put into payload) will be those of JobB also for JobA.
I have tried to identify where this issue is coming from but can currently can not pinpoint it exactly nor propose a solution.
Hope this will make immediate sense to @themsaid
Kind regards, Graem
The text was updated successfully, but these errors were encountered: