-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Select alternatives on missing receiver arg or typo #27230
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
|
||
public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, string $defaultReceiverName = null) | ||
public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = null) |
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.
I think keeping the defaultReceiver argument would be better than arbitrary selecting the first one.
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.
As we don't have default receiver by definition I'm selecting the first one and the only one when there is just one receiver... but I guess out-of-the-box could makes sense set a default one among several... still worth it?
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.
I think we should never select a default ourself if many receivers are available. Within the fwb, this means just exposing the whole list except when there is only one receiver.
Without, it's the developper responsibility to set one.
I feel like selecting arbitrary the first receiver is against DX.
(but, interactively in the command, the choice question could have a default, as it still requires validating it)
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.
But as far as I understand the code now, it only selects the first one only if there is only one receiver, so that works well.
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.
😅 good point. I missed that.
I guess everything is fine then 😛
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.
Small tweak in the test to prove it https://github.com/symfony/symfony/pull/27230/files#diff-9a060054c9ccf980baeb5ee6e153c5a2R34
@@ -183,8 +182,12 @@ private function registerReceivers(ContainerBuilder $container) | |||
} | |||
} | |||
|
|||
if (1 === \count($taggedReceivers) && $container->hasDefinition('console.command.messenger_consume_messages')) { | |||
$container->getDefinition('console.command.messenger_consume_messages')->replaceArgument(3, (string) current($receiverMapping)); | |||
if ($container->hasDefinition('console.command.messenger_consume_messages')) { |
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.
Relates to above, I think we should only have the default defined if there is just one like in removed lines (but still inject all names independently for interactivity)
5f702be
to
4c98ba8
Compare
Rebased and ready. |
4c98ba8
to
54c2541
Compare
I’m afraid that such interaction would cause troubles when developers add
another transport but forget to update their worker script: it would prompt
the transport same rather than failing so their monitoring wouldn’t pick it
up (obsly when they run the worker somewhere that “supports” interactions).
…On Fri, 11 May 2018 at 15:49, Yonel Ceruto ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Symfony/Component/Messenger/Command/ConsumeMessagesCommand.php
<#27230 (comment)>:
>
- public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, string $defaultReceiverName = null)
+ public function __construct(MessageBusInterface $bus, ContainerInterface $receiverLocator, LoggerInterface $logger = null, array $receiverNames = null)
Small tweak in the test to prove it
https://github.com/symfony/symfony/pull/27230/files#diff-9a060054c9ccf980baeb5ee6e153c5a2R34
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#27230 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAxHEdd8CzFRKR22oPaINOQvF8kCsVdcks5txZcFgaJpZM4T6mOr>
.
|
Is that really an issue? |
I agree completely with @ogizanagi. It's really useful only for development. In production you must always configure the receiver argument without interaction. |
What about to disable the interaction mode on debug false ? |
That is a great idea 👍
…On Mon, 14 May 2018 at 14:03, Yonel Ceruto ***@***.***> wrote:
What about to disable the interaction mode on debug false ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#27230 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAxHEWJSWIwIUwOFN3eRp-1ZtH9mJd61ks5tyYCIgaJpZM4T6mOr>
.
|
That would still not solve the case the dev adds a receiver where previously there was only one and the script calls the command without explicit arguments (hence fails). So, also make the argument required if no debug? |
@@ -134,4 +158,21 @@ private function convertToBytes(string $memoryLimit): int | |||
|
|||
return $max; | |||
} | |||
|
|||
private function findAlternatives($name, array $collection) |
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.
Isn't this already somewhere else? Can't we share instead of copy? Maybe at least reference the other occurrences if it has been pasted so we know when maintaining it?
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.
Yes, from debug command of the Form component, but still there is other places where similar procedure has been used, probably a trait
could be created for such cases.
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.
We don"t have a central place for such logic for 2 reasons: it's small enough and we don't want to create a "util" component.
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.
@fabpot a good practice can be to add a comment that refers to the place it was copy/pasted from.
Thank you @yceruto. |
…g or typo (yceruto) This PR was merged into the 4.1 branch. Discussion ---------- [Messenger] Select alternatives on missing receiver arg or typo | Q | A | ------------- | --- | Branch? | 4.1 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - If there is more than one receiver available - `bin/console messenger:consume-messages`:  If typo and there is similarities - `bin/console messenger:consume-messages amq`:  requires #27224 Commits ------- 54c2541 Select alternatives on missing receiver arg or typo
If there is more than one receiver available -

bin/console messenger:consume-messages
:If typo and there is similarities -

bin/console messenger:consume-messages amq
:requires #27224