remove the return value of dispatch()+handle(): we never use it and it contradicts the very idea of async (mutable messages can be used instead, but that's not our business)

what about query bus? It would be nice provide query bus out of the box

what about query bus? It would be nice provide query bus out of the box

They could use mutable command objects (e.g. a setResult()). This would benefit the type system since the argument to this method could be type-hinted.

Right now, the return value blurs the scope of the component to me. Also look at e.g. ChainHandler: returning the array of all results makes no sense: this is configuration leaking to the outside.
Makes sense?

make everything internally deal with Envelope objects (middlewares, transports, etc.)

I didn't review this yet, but you've got my 👍 for this. I already suggested this in the past (#27322) and suggested an abstract Middleware class for those wanting only to deal with messages in their middleware.

Meanwhile, I'm not convinced EnvelopeHandlerInterface would be useful.

Meanwhile, I'm not convinced EnvelopeHandlerInterface would be useful.

Since Envelope is not an internal detail, it means ppl that use it to wrap their messages should be able to receive them also. Otherwise, why allow dispatching envelope in the first place? To me, either we make Envelope purely internal (ie never dispatch them) - or handlers need to be able to receive them, in an opt-in way.

Note that I may be missing the reason why #27322 has been rejected: right now, I'm thinking about middlewares as things that are tightly bound to Messenger so that they legitimately know about it, and about Envelope especially.
The boundary that is loosely coupled is the caller of dispatch(), and it's corresponding handlers. Those don't need to care about Envelope.
So, @sroze maybe: what are the use cases you envision where middlewares are on the outer boundary of the component?

Since Envelope is not an internal detail, [...] handlers need to be able to receive them, in an opt-in way.

It's not about the envelope being internal or not regarding this. Envelopes are meant for runtime "config" of middleware & transports. If the handler needs some data to treat the message, it should be part of it, not the envelope.

If the handler needs some data to treat the message, it should be part of it, not the envelope.

aren't there any cases where the handler will want to know about the way routing did happen? E.g. number of retries, timestamps, some routing/logging identifier, etc. - Things that could be of interest for some handlers?

Obviously not to me. Handlers are pure business logic. The use-cases you mention are valid as a middleware (which if really needed can mutate the message, but those are usually supposed immutable).

Handlers are pure business logic. The use-cases you mention are valid as a middleware

Argument accepted, makes perfect sense. That's another argument to make middlewares deal with envelopes: they're part of the routing - use handlers for the part that is outside.

Closing here because this has been split into several PRs already - or will soon be for the remaining ideas.
See #28914, #28911, #28909, #28908, #28907