[Messenger] Make MessengerPass less strict when auto-register handlers #29525
Conversation
|
Well, usually handlers should be pure business/application logic and envelope stamps mostly technical stuff about the transport or cross cutting concerns from middleware. If the data you need from stamps is relevant to the handler, you should think twice if it should not be part of the message itself. If it can't and can only be added as a stamp, is it really the handler's responsibility to be aware of this and act accordingly? But actually on my side, I'm not against this PR right now. I even thought to suggest this before but was waiting for real demands. What I expressed above only is my own experience with buses within CQRS applications. Not canonical. And bringing more flexibility here might be interesting without implying much overhead. |
|
@ogizanagi Yeah, I don't know how common this would be but our need comes from using PubNub and having to apply the channel to respond to when sending another message from the handler. Having the channel be part of the message is a solution but that would really mix infrastructure concerns with our business logic. |
|
But having the envelope be part of the message is also mixing infrastructure (sf messenger) with domain logic 🤔 It sounds like a middleware concern IMHO. |
|
@ro0NL It's true, if it's possible to have information from one message to another in the middleware then let me know. Also, handlers you can change, messages you really shouldn't change too much. |
|
I agree with @ro0NL: handlers are designed to get only the message and not the envelope. |
|
@nicolas-grekas Yeah, we did solve it with a custom middleware, but it's not really a nice experience atm, but doable. One problem still exist with auto-register handlers with more than one invoke parameters. I think the message-pass should look like what I did in this PR. |
| @@ -207,8 +207,8 @@ private function guessHandledClasses(\ReflectionClass $handlerClass, string $ser | |||
| } | |||
|
|
|||
| $parameters = $method->getParameters(); | |||
| if (1 !== \count($parameters)) { | |||
| throw new RuntimeException(sprintf('Invalid handler service "%s": method "%s::__invoke()" must have exactly one argument corresponding to the message it handles.', $serviceId, $handlerClass->getName())); | |||
| if (0 === \count($parameters)) { | |||
There was a problem hiding this comment.
maybe use getNumberOfRequiredParameters?
There was a problem hiding this comment.
I changed it, although not sure if it helps against (Message $message = null) since you could have (Message $message = null, Envelope $envelope)?
|
I updated the PR to only deal with auto-registering in MessengerPass. |
|
the changes seem reasonable to me |
src/Symfony/Component/Messenger/DependencyInjection/MessengerPass.php
Outdated
Show resolved
Hide resolved
303051a to
49ab2cd
Compare
|
Thank you @nicholasruunu. |
…ister handlers (nicholasruunu) This PR was merged into the 4.3-dev branch. Discussion ---------- [Messenger] Make MessengerPass less strict when auto-register handlers | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | License | MIT | Doc PR | not needed This allows you to auto-register handlers that have more than one argument, which is useful when having custom middleware to pass more parameters. #symfonyconhackday2018 Commits ------- 49ab2cd Make MessengerPass less strict when auto-register handlers
This allows you to auto-register handlers that have more than one argument, which is useful when having custom middleware to pass more parameters.
#symfonyconhackday2018