[12.x] Add SQS FIFO and fair queue messageGroup() method support #57421
+179
−8
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 is a follow up to the previous PR #57187 that extended SQS FIFO and fair queue support to mailables, notifications, and event listeners. This PR adds support for defining a
messageGroup
method on the job classes instead of requiring the use of theonGroup()
method at time of dispatch. See discussion on previous PR starting here.Summary
Normal jobs, mailables, and notifications are actively dispatched by the user and have the ability to call
onGroup()
at the time of dispatch. However, event listeners are not dispatched by the user. They are predefined ahead of time (with class methods), and then dispatching the event triggers the listener. There is nowhere for the user to callonGroup()
for a class-based event listener.Due to this, there was an inconsistency where event listeners supported a
messageGroup()
method on the class, but all the other job types required callingonGroup()
at the time of dispatch.To help add some consistency, this PR adds support for defining a
messageGroup()
method on the other job types, as well. This also allows the message group logic to remain encapsulated inside of the job and not need to be provided by the dispatching logic.Notes
The
messageGroup()
method does not take any parameters.The value of the
$messageGroup
property takes precedence over themessageGroup()
method. This allows the dispatcher to still callonGroup()
and have that value used instead of themessageGroup()
method.For notifications, the new
messageGroup()
method support is in addition to the existing support for thewithMessageGroups($notifiable, $channel)
method, which takes the notifiable and channel in as parameters to determine the message group.Please let me know if you need me to make any changes or have any questions.