Moving the AMQP exchange from env var to config

[weaverryan]

Q	A
License	MIT

This should make it easier (more obvious how) to specify multiple transports using the same
AMQP connection config, but with different exchanges. Using a different exchange for each transport is the "main" way of supporting multiple transports (you can also use 1 exchange with multiple queues, but then it's up to you to change the exchange type to direct and manage binding and routing keys).

Docs issue: symfony/symfony-docs#11713

From Twitter convo: https://twitter.com/webdevilopers/status/1136177625406332928?s=21

Cheers!

[ghost]

Pull request passes validation.

[ghost]

Pull request passes validation.

[Tobion]

Maybe using ?exchange[name]=messages is more self-explaining. Using the path for the virtual host and exchange is not self-explaining at all.

[Tobion]

or using the config options directly below the dsn. this would also make sure that options passed in the dsn would keep working. Something like

async:
    dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
    options:
        exchange:
            name: messages

[webdevilopers]

This indeed makes it more obvious! 👍

I'm no Redis user but does this change apply to the "messages" suffix too?
MESSENGER_TRANSPORT_DSN=redis://localhost:6379/messages
Or is this a general "collector"?

I also like the suggestions by @Tobion . I guess this should be added to docs in a different PR.

async:
    dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
    options:
        exchange:
            name: messages

He states this would also make sure that options passed in the dsn would keep working.
If I remember correctly setting a custom exchange in the config will not be "recognized" as long as the default exchange was set inside the env?

[weaverryan]

Sorry for the delay in replying!

I realized, thanks to your suggestion, that my PR in fact does not work. The problem is that this async transport is currently written to work with any transport that you configure in .env - amqp, but also maybe doctrine or redis.

So, I'm not sure what to do. the only way to make messenger.yaml fully work for any transport is for 100% of the connection config to be in .env. My ideas include:

A) Do nothing. Close this PR, and update the AMQP documentation to help people.
B) Create 3 different async examples in messenger.yaml, one for redis, doctrine & amqp. I'm not sure I love this - that's a lot of noise in that file, and you'd now need to know which example to uncomment.

[fabpot]

I would be in favor of option A.

[maxhelias]

I realized, thanks to your suggestion, that my PR in fact does not work. The problem is that this async transport is currently written to work with any transport that you configure in .env - amqp, but also maybe doctrine or redis.

Normally every transport has his own parser for support this or i'm wrong ?

[weaverryan]

Normally every transport has his own parser for support this or i'm wrong

You're right - every transport supports different options as query parameters (or under the options key). The problem is that the amqp transport in messenger.yaml is meant to be "generic" - it's meant to work out-of-the-box with any transport. And so, it can't contain any transport-specific options.

I'm going to open a docs issue about this, and will hopefully document it soon.