Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[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

Closed
dkarlovi opened this issue Sep 4, 2023 · 6 comments · Fixed by #59198

Comments

@dkarlovi
Copy link
Contributor

dkarlovi commented Sep 4, 2023

Symfony version(s) affected

6.3.3

Description

When running messenger:consume without a transport, it asks to select which transport to consume from.

$ bin/console messenger:consume

                                                                                                                        
 Which transports/receivers do you want to consume?                                                                     
                                                                                                                        

Choose which receivers you want to consume messages from in order of priority.
Hint: to consume from multiple, use a list of their names, e.g. async, default

 Select receivers to consume: [async]:
  [0] async
  [1] default

But, if I select default (which is sync), it immediately throws

In SyncTransport.php line 37:
                                                                 
  You cannot receive messages from the Messenger SyncTransport.  
                                                                 

making 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.

@dkarlovi dkarlovi added the Bug label Sep 4, 2023
fabpot added a commit that referenced this issue Dec 4, 2023
…(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`
symfony-splitter pushed a commit to symfony/messenger that referenced this issue Dec 4, 2023
…(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`
@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@dkarlovi
Copy link
Contributor Author

dkarlovi commented Mar 6, 2024

Yup.

@carsonbot carsonbot removed the Stalled label Mar 6, 2024
@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@carsonbot
Copy link

Just a quick reminder to make a comment on this. If I don't hear anything I'll close this.

@dkarlovi
Copy link
Contributor Author

AFAIK this wasn't fixed in other related PRs but was mentioned as a nice to have.

@carsonbot carsonbot removed the Stalled label Sep 21, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 12, 2024
@wazum
Copy link
Contributor

wazum commented Dec 12, 2024

I tried to solve this, please take a look at the pull request.

wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Dec 13, 2024
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
wazum added a commit to wazum/symfony that referenced this issue Feb 17, 2025
fabpot added a commit that referenced this issue Feb 26, 2025
…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`
@fabpot fabpot closed this as completed Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants