[Messenger] Add a --bus option to the messenger:consume-messages command #28190
Conversation
| $buses[$busId] = new Reference($busId); | ||
| } | ||
| $container->getDefinition('console.command.messenger_consume_messages')->replaceArgument(0, ServiceLocatorTagPass::register($container, $buses)); | ||
| $container->getDefinition('console.command.messenger_consume_messages')->replaceArgument(4, $busIds); |
There was a problem hiding this comment.
spare out an additional getDefinition call by chaining the 2nd replaceArgument?
| if ($alternatives = $this->findAlternatives($busName, $this->receiverNames)) { | ||
| $style->block(sprintf('Bus "%s" is not defined.', $receiverName), null, 'error', ' ', true); | ||
| if ($style->confirm(sprintf('Do you want to dispatch to "%s" instead? ', $alternatives[0]), false)) { | ||
| $input->setArgument('receiver', $alternatives[0]); |
There was a problem hiding this comment.
this should set the bus option no? Also it's at least weird to pick the first one instead of presenting a choice question here.
| $style = new SymfonyStyle($input, $output); | ||
| if (null === $receiverName) { | ||
| $style->block('Missing receiver argument.', null, 'error', ' ', true); | ||
| $input->setArgument('receiver', $style->choice('Select one of the available receivers', $this->receiverNames)); |
There was a problem hiding this comment.
You could set the $receiverName variable here, nah?
|
|
||
| public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = array()) | ||
| public function __construct(ContainerInterface $busLocator, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = array(), array $busNames = array()) |
There was a problem hiding this comment.
This is a BC break. Can you update the UPGRADE file?
There was a problem hiding this comment.
@sroze Can you add a note in the CHANGELOG?
c7dec58 to
2f873f1
Compare
3ca0dbd to
0fb758d
Compare
| <argument type="service" id="messenger.receiver_locator" /> | ||
| <argument type="service" id="logger" on-invalid="null" /> | ||
| <argument>null</argument> <!-- Default receiver name --> | ||
| <argument type="collection" /> <!-- Message buses names --> |
0fb758d to
99a4f5f
Compare
|
|
||
| public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = array()) | ||
| public function __construct(ContainerInterface $busLocator, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = array(), array $busNames = array()) |
There was a problem hiding this comment.
@sroze Can you add a note in the CHANGELOG?
99a4f5f to
b077e78
Compare
b077e78 to
e3f1eec
Compare
|
CHANGELOG updated and deps=low build fixed (remaining failures unrelated). Ready, thanks @sroze for the commit. |
|
Thank you @chalasr. |
…e-messages command (chalasr, sroze) This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] Add a --bus option to the messenger:consume-messages command | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | todo Making it compatible with the multi-bus feature. Commits ------- e3f1eec Bus argument is a required option when multiple buses are defined 539cb62 [Messenger] Add a --bus option to the messenger:consume-messages command
|
@symfony/deciders: right now, our CI is broken since several days because of this BC break. This means breaking BC is more painful than writing a proper BC layer. With this bad experience in mind, I'd suggest stopping doing BC breaks even if the component is experimental. I don't know how to fix the current failures, while I know how to write proper BC layers. |
|
I'd suggest reverting #28328 and replacing the BC break introduced here by a proper BC layer. |
|
What about restricting the version constrains in Composer instead? That would better reflect the experimental status of the component. |
|
maybe a strategy could be to add a BC layer and semi-regular intervals work on removing (parts of the) the BC layer again ensuring the test suite isn’t broken. this could help maintain development speed. another approach could be to simply move the developmen to another repo and resync only when the test suite is fixed in the PR. |
|
The CI did catch the breakage. Doing things in a separate repo might make things harder I fear. Having framework-bundle 4.1 accept only messenger 4.1 is a strategy that would work yes. Currently, breaking BC is painful, which is a good thing actually, since it should be. But maybe not for an experimental component. Do you confirm we should go this way @fabpot? I can then revert #28328 and replace it with a conflict >=4.2 rule instead. |
|
I don't think it makes sense to revert #28328 as it's a valid change. |
|
I confirm that restricting the version constraints is the way to go IMHO. |
…the PR #28190 (sroze) This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] Ensure the tests and implementation matches the PR #28190 | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #28190 | License | MIT | Doc PR | ø And we should have master green. Commits ------- ba62485 Ensure the tests and implementation matches the merged #28190 PR
Making it compatible with the multi-bus feature.