[Messenger] add event for all handled messages even failing one #32614
Conversation
There was a problem hiding this comment.
I think this makes sense, but I'm not sure we need two events. The new placement of WorkerMessageHandledEvent might be enough, except that we could now pass a boolean flag to it to indicate whether or not the message was handled successfully (and add some wasHandledSuccessfuly() method to the object).
src/Symfony/Component/Messenger/Event/WorkerMessageHandledSuccessfullyEvent.php
Show resolved
Hide resolved
|
@weaverryan So we would have both The thing I am concerned about is how can we properly document that the Perhaps it adds unnecessary complexity for the end user? One would ask himself if he should subscribe to Would love to have other opinions :-) |
|
Friendly ping @weaverryan |
1 similar comment
|
Friendly ping @weaverryan |
|
No, I meant that we would only have one event WorkerMessageHandledEvent - but in the new location where you’ve placed it. There would be no other event. But then on that event, we would pass whether or not the message was successful to that event class so that the user can use it to determine if the message was successfully handled or not. Or, we have two events - but one explicitly only for failed messages (WorkerMessageHandlingFailedEvent) and another explicitly only for successful messages (WorkerMessageHandlesSuccessfullyEvent). As I understand it now, with this PR, we have 2 events, but one is called always and the other only on success. Why not just 1 event for both cases or 2 events that are mutually exclusive? Sorry for the delay! |
|
Makes sense to have 1 event like proprosed. I will update the PR soonish. Thanks 👍 |
|
In fact, I am not sure when I will have the time to work on this. |
|
Closing in favor of #34217 |
This PR was merged into the 4.4 branch. Discussion ---------- [Messenger] use events consistently in worker | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | yes | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | Fix #32560, #32614, #33843 | License | MIT | Doc PR | The worker had the three ways to handle events 1. $onHandledCallback in `run(array $options = [], callable $onHandledCallback = null)` 2. events dispatched using the event dispatcher 3. hardcoded things inside the worker This PR refactores the messenger worker to only use event dispatching. So instead of a hardcoded `$onHandledCallback` and worker decorators, we use event listeners and we don't need a `WorkerInterface` at all. The behavior of all the options like `--memory-limit` etc remains the same. I introduced two new events - `WorkerStartedEvent` - `WorkerRunningEvent` Together with the existing `WorkerStoppedEvent` it's very symmetrical and solves the referenced issues. Commits ------- 201f159 [Messenger] use events consistently in worker
fix #32560 by dispatching
WorkerMessageHandledEventon every handled messages instead of successful ones.I rename the current
WorkerMessageHandledEventtoWorkerMessageHandledSuccessfullyEventto make things more explicit and keep that extension point.