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
So right now it's "impossible" (nothing is of course) to configure the queue on which the subscription is broadcasted (if you choose to use the queue).
This is because an event/listener is used, because Laravel handles reading the $queue property very poorly and you cannot set it in the constructor or implement a getter method (bit more context).
There are a few options I see and I wanted to discuss it before creating a PR. Hope to discuss the solutions below and/or read better options.
1. Remove the use of a event/listener
And use a proper queued job on which we can run onQueue and use other methods to set the queue name read from the config file.
2. Read the event listener class from the container
Use an interface to read the event listener implementation from the container so the user can implement it's own (extend the current one and set the $queue property).
3. Use a "hack"
Defining this function on the event listener would work:
I'm partial to 1 because it allows us to just add a config option to set the queue name and use an actual queue job instead of queued event allowing us to set tags for Horizon too (see #1301).
But 2 sounds the most simple from a code perspective seeing as everything uses an interface already.
However 1 is probably a breaking change (removing the event) although we could trigger the new job from the event listener and remove the ShouldQueue from the event listener to solve that "issue" and add it to the 4.12 release.
3 is possible but seems like a terrible plan 😄
The text was updated successfully, but these errors were encountered:
So right now it's "impossible" (nothing is of course) to configure the queue on which the subscription is broadcasted (if you choose to use the queue).
This is because an event/listener is used, because Laravel handles reading the
$queue
property very poorly and you cannot set it in the constructor or implement a getter method (bit more context).There are a few options I see and I wanted to discuss it before creating a PR. Hope to discuss the solutions below and/or read better options.
1. Remove the use of a event/listener
And use a proper queued job on which we can run
onQueue
and use other methods to set the queue name read from the config file.2. Read the event listener class from the container
Use an interface to read the event listener implementation from the container so the user can implement it's own (extend the current one and set the
$queue
property).3. Use a "hack"
Defining this function on the event listener would work:
I'm partial to 1 because it allows us to just add a config option to set the queue name and use an actual queue job instead of queued event allowing us to set tags for Horizon too (see #1301).
But 2 sounds the most simple from a code perspective seeing as everything uses an interface already.
However 1 is probably a breaking change (removing the event) although we could trigger the new job from the event listener and remove the
ShouldQueue
from the event listener to solve that "issue" and add it to the 4.12 release.3 is possible but seems like a terrible plan 😄
The text was updated successfully, but these errors were encountered: