You say the handler is removed, but below is „allow_no_handlers“... it is a bit confusing

Actually themiddleware is removed in favor of a flag in theHandleMessageMiddleware. I believe this information isn't really useful from the config POV so I omit it and just talk about setting theframework.messenger.[bus].default_middleware config option toallow_no_handlers to set this flag.
How can I improve this?

if it's too hard to explain.. i suggested#28945 (comment) 👼

@ro0NL : At least, I agreeallow_no_handlers at the bus node level would be self-explanatory.

it also brings more flexibility, i.e. keep logging but disable other defaults.

Being able to control it per case, IMHO would be more straightforward. Currently it's a bit all or nothing, and you need to know what default_middleware=true actually means.

That's why I was never really convinced by the default middleware config over explicit middleware stack configuration.

but then we cant provide sensible defaults (including default ordering).. so having a node per default + custom middleware stack seems like best of both.

So the only "weird" case is, if you want re-order defaults

bus:logging:false# log beforemiddleware:[custom, logging]# log after

That still requires knowledge about what the defaults are and their order.

We could add aframework.messenger.default_middleware withbefore andafter entries (or a[middleware] placeholder for specific bus middleware), with same format as middlewares & default values set in theConfiguration allowing these to be dumped ondebug:config and changed in userland so anyone can provide their own defaults, but not sure it is worth.

framework:messenger:default_middleware:~# Which by default is the same as:# default_middleware:#   before:#     - logging#   after:#     - route_messages#     - call_message_handlerbuses:messenger.bus.command:middleware:                    -doctrine_transactionmessenger.bus.query:default_middleware:falsemiddleware:                    -cache                    -call_message_handlermessenger.bus.event:allow_no_handlers:true

But defaults may also be a PITA if one day we need to deprecate a middleware part of defaults in favor of another one. We cannot either add more or remove one in the future.

IMHO, explicit is always better.

maybe you're right 👍 the defaults are not super complex to declare anyway...