-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Messenger: fix for interface_exists #26896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for the interface_exists
, l was meant to look at why it was auto enabling it today hehe. But... the Sender is valid isn’t it?
@@ -347,8 +347,6 @@ public function load(array $configs, ContainerBuilder $container) | |||
->addTag('validator.initializer'); | |||
$container->registerForAutoconfiguration(ReceiverInterface::class) | |||
->addTag('messenger.receiver'); | |||
$container->registerForAutoconfiguration(SenderInterface::class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would you remove that? 🤨
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not needed, right? I can't find any reference to it (at least in the current master). Basically, in FrameworkExtension
, it looks we loop over the routing, then put each sender into the sender locator. In other words, we don't actually use the tag. But, yea, I'm wondering if I'm wrong and missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, you are right actually. But we do create the senders with this tag. And I believe that we should actually create the $senderLocatorMapping
in the MessengerPass
, based on the tagged messenger.sender
services (same as we do with receivers). (but keep the $messageToSenderIdsMapping
generated in the FrameworkExtension
.
So... I'd say either you change this in that PR or it's out of scope for this one and I'll open one to use the messenger.sender
tag 🙃
467977b
to
7fcacf0
Compare
7fcacf0
to
2405eae
Compare
@sroze I've just taken out my autoconfiguration removal - so this PR is now dead-simple :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@weaverryan I've updated the tests within your PR as well. |
Though, it breaks the tests with a service that has a dependency on the |
Thank you @weaverryan. |
This PR was merged into the 4.1-dev branch. Discussion ---------- Messenger: fix for interface_exists | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no-> | Tests pass? | yes | Fixed tickets | none | License | MIT | Doc PR | not needed 2 unrelated bugs! But, very minor :). Commits ------- d60425c Allow the logger to be null (as per every other bits in the FrameworkBundle) 3c4be3c Update the tests to also use `interface_exists` 2405eae Fixing bad class_exists vs interface_exists
2 unrelated bugs! But, very minor :).