[11.x] Add support for middlewares & failed handler on broadcastable events #54562
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces support for using middlewares & a failure handler on broadcastable events.
Currently, classes utilizing the
ShouldBroadcast
interface are internally transformed to aBroadcastEvent
job. This job supports proxying a few of job-specific properties, such as$queue
,$connection
,$tries
, etc., to allow customizing when/how the queueable job is processed. One of the big drawbacks is not being able to define middlewares & job failures, which I, in fact, already expected to work as this can be very handy.As this should be possible by proxying the data from the original event, just as is the case for some of the aforementioned properties, I would expect to this work when using broadcasting via queue.
Solution
This PR solves this issue by forwarding the middlewares defined on the original event via the
middlewares
method to theBroadcastEvent
job.The other drawback, job failure, can also now be solved by defining a
failed
method on the original event.In summary, the following is now possible:
Possible drawback
The underlying middleware will instead receive a
BroadcastEvent
, instead of theTestEvent
, as the actual job that is processed by our selected queue driver is used on is theBroadcastEvent
job, which wraps the original event. Meaning, the event is easily accessible via$job->event
, so I'd, in fact, say this should be completely fine and a little mention in the docs should be enough.Discussion
I'm not 100% decided whether using methods, or properties, should be preferred. Perhaps.. both could work? I'm unsure on what the priority is between
$middleware
&middleware()
on a job.