Does the definition of the "queue" belong to the place that calls dispatch (ie user code)
or does it belong to the routing layer?
Shouldn't this be handled by using virtual transports instead? Why "queue" btw?

Does the definition of the "queue" belong to the place that calls dispatch (ie user code)
or does it belong to the routing layer?

That's a fair question. The message->transport routing is a natural fit for config, because you're using keys that are only defined in config - e.g. "send to theamqp transport -amqp is defined in config, so it fits nicely to "route" itfrom config (it would look a little funny if you were to mention this string in a controller or service). But, with queues, these aren't defined anywhere - you can just "invent them" at the time you dispatch - and whatever transport the message goes to will handle that. But, I'm not absolutely convinced one way or another.

Shouldn't this be handled by using virtual transports instead?

This is certainly a possibility - a "virtual" transport that basically "adds the queue name metadata to the message and forwards to the real transport".

Overall, it's a matter of:
A) Configuration at dispatch time via stamp
vs
B) Configuration in config via routing

The first gives nice, clear control per message. But it's harder to apply a stamp automatically to all classes that implement some interface or to messages dispatched by a 3rd party (you'd need an event listener). The second would require a new concept (virtual transports) and puts more config into YAML... which I don't love ;).

Why "queue" btw?

I'm not an AMQP expert, but AMQP has queues, and that's literally what you're doing here: putting each message into a different AMQP queue, then consuming on a queue-by-queue basis. For DoctrineTransport, it's actually just a column on the table (queue). But using the "standard" name from AMQP as the standard name/concept I think makes sense.

The second would require a new concept (virtual transports)

This PR is already a new concept - the stamp + the "queue" concept.
A virtual transport is less of a new concept as its ... a transport :)
But the real question is: where belongs the responsibility of deciding the queue/transport?
I don't think the dispatch point is the correct place - exactly same as deciding the transport doesn't belong there.
There is senderLocator - that's where this routing belongs, no need for a new concept here - a variation of the existing one fits to me.

But, with queues, these aren't defined anywhere - you can just "invent them" at the time you dispatch

That's for AMQP-only. If you use Google Pub/Sub, Amazon SQS and so on, I believe you need to define them upfront.

where belongs the responsibility of deciding the queue/transport?
I don't think the dispatch point is the correct place

I agree this this.

I don't believe we need any new concept for this. Not even a "virtual transport". Why can't they just be to different transports, namedhigh_priority_amqp andlow_priority_amqp? The "only" thing we need to add is the ability for the Worker to consume messages from multiple transports at a time.

I think@sroze is right. I'm closing this PR in favor of#30708, which I can further enhance to allow for handling multiple transports inside a single Worker.