-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] messenger:consume offers sync transports to consume from and then immediately throws an exception #51556
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
Comments
…(javaDeveloperKid) This PR was squashed before being merged into the 7.1 branch. Discussion ---------- [Messenger] Add `--all` option to `messenger:consume` | Q | A | ------------- | --- | Branch? | 7.1 | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Issues | Closes #52364 <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead --> | License | MIT When implementing this feature the problem with sync transports came out so the `if` statement for this was needed. I can see someone reported this 2 months ago in #51556. I think this be can fixed properly in a dedicated PR because it requires to dig into MessengerPass I guess. Commits ------- ae454e0 [Messenger] Add `--all` option to `messenger:consume`
…(javaDeveloperKid) This PR was squashed before being merged into the 7.1 branch. Discussion ---------- [Messenger] Add `--all` option to `messenger:consume` | Q | A | ------------- | --- | Branch? | 7.1 | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Issues | Closes #52364 <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead --> | License | MIT When implementing this feature the problem with sync transports came out so the `if` statement for this was needed. I can see someone reported this 2 months ago in symfony/symfony#51556. I think this be can fixed properly in a dedicated PR because it requires to dig into MessengerPass I guess. Commits ------- ae454e0648 [Messenger] Add `--all` option to `messenger:consume`
Hey, thanks for your report! |
Yup. |
Hey, thanks for your report! |
Just a quick reminder to make a comment on this. If I don't hear anything I'll close this. |
AFAIK this wasn't fixed in other related PRs but was mentioned as a nice to have. |
…ble tag attribute Fixes symfony#51556
…ble tag attribute Fixes symfony#51556
…ble tag attribute Resolves symfony#51556
I tried to solve this, please take a look at the pull request. |
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…ble tag attribute Resolves symfony#51556
…tering `ConsumeMessagesCommand` (wazum) This PR was squashed before being merged into the 6.4 branch. Discussion ---------- [Messenger] Filter out non-consumable receivers when registering `ConsumeMessagesCommand` | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #51556 | License | MIT This pull request enhances the `MessengerPass` in the Symfony Framework Bundle to automatically filter out non-consumable receivers when registering the `ConsumeMessagesCommand`. The key changes are: The FrameworkExtension has been updated to mark the "sync" transport as non-consumable by default, without requiring the user to explicitly set the `is_consumable` attribute. The `MessengerPass` then checks the `is_consumable` attribute on the `messenger.receiver` tags. If the attribute is set to `false`, the receiver is considered non-consumable and will not be added to the list of receivers for the consume command. If there is only one consumable receiver, the consume command will automatically use that receiver without prompting the user to select one (I added this as a separate commit if this is too implicit). These changes improve the user experience by removing unnecessary (and non-functioning) options. This is my first pull request for the _Symfony_ project, so please let me know what I can improve. Commits ------- 34c7e6f [Messenger] Filter out non-consumable receivers when registering `ConsumeMessagesCommand`
Symfony version(s) affected
6.3.3
Description
When running
messenger:consume
without a transport, it asks to select which transport to consume from.But, if I select
default
(which is sync), it immediately throwsmaking this choice superfluous because the only possible selection is
async
.How to reproduce
See above.
Possible Solution
Filter out sync transports and, if only one item remains, consume that immediately.
Additional Context
I guess this could be considered an UX bug.
The text was updated successfully, but these errors were encountered: