it becomes impossible to type-hint the MessageBusInterface

you'll get the default bus AFAIK...

You can now typehint your CommandBus

What if the same decorated class is used multiple times across buses?

isn't this just like sayingMy\CommandBus: '@messenger.bus.command', using regular DI wiring. Put different; do we really want/need this feature?

What if the same decorated class is used multiple times across buses?

Well, you know what is going to happen: the auto-wiring won't be happy :)

isn't this just like saying My\CommandBus: '@messenger.bus.command', using regular DI wiring. Put different; do we really want/need this feature?

Ish. It still means you'd have to create theMy\CommandBus class, but it's a good point. Should we go with just the class and no FWB configuration?

Or just a trait maybe =/ i would indeed avoid the FWB config.

It works well with the following configuration 👍

services:'App\Bus\CommandBus':decorates:"messenger.bus.commands"

To be completed by a lovely documentation :)

In development, with the following configuration:

services:'App\Bus\CommandBus':decorates:"messenger.bus.commands"

The decorated bus is an instance ofSymfony\Component\Messenger\MessageBus notSymfony\Component\Messenger\TraceableMessageBus

@kbond you need to typehint itherMessageBusInterface or your ownApp\Bus\CommandBus notSymfony\Component\Messenger\MessageBus 😉

@sroze I type-hinted my own bus which extends fromAbstractMessageBusDecorator. The$decoratedBus property is not and instance ofSymfony\Component\Messenger\TraceableMessageBus

It is the correct bus it just doesn't show any activity in the profiler.

I'm sorry but I don't understand the problem... "it works well on my machine" 😅 Can you give me the exact error you face and the classes & configuration you have? :)

There is no error.

messenger config:

framework:messenger:default_bus:eventbuses:command:default_middlewares:falsemiddlewares:                    -logging                    -Symfony\Bridge\Doctrine\Messenger\DoctrineTransactionMiddleware                    -call_message_handlerquery:default_middlewares:falsemiddlewares:                    -logging                    -call_message_handlerevent:middleware:                    -tolerate_no_handler

service config:

services:App\Messenger\CommandBus:decorates:messenger.bus.command

my command bus class:

namespaceApp\Messenger;useSymfony\Component\Messenger\AbstractMessageBusDecorator;finalclass CommandBusextends AbstractMessageBusDecorator{}

controller injecting command bus:

publicfunctionmyAction(CommandBus$commandBus){dump($commandBus);// ...}

Screenshot of dumped$commandBus:

Notice the decorated bus is justMessageBus notTraceableMessageBus.

Note, if I change my service config to:

services:App\Messenger\CommandBus:['@messenger.bus.command']

TheTraceableMessageBus is the decoratedBus.

Oh, excellent. Thank you for checking that. That's what will be in the documentation then :)

Status: Ready

@weaverryansymfony/symfony-docs#9727

I'm very skeptical about this PR and the related § insymfony/symfony-docs#9727.
This encourages type-hinting against a concrete implementation and totally breaks SOLID, isn't it?
I acknowledge there is a DX issue and that this proposal tries to solve it. Coincidentally, I was talking about the exact same issue with@weaverryan today, telling him about a solution we might want to push forward in 4.2 (it's too early to elaborate here for now).

No need for any dedicated interfaces, using bindings solves the issue:
$commandBus: @messenger.bus.command

Outch. Not sure how I feel about that one. I'll give a try.

As explained, I'm:-1: as this would put users in a dead end. We should tell about using bindings instead, and seek for a better experience in 4.2 that doesn't break SOLID.

Closing, as I'll update the documentation to recommend the binding, that makes sense actually.