Do you have a specific use-case for this? If we really need to add such thing, wouldn't it be better to have a NotSerializableEnvelopeItemInterface, so it's explicit and we keep it serializable "by default"?

Do you have a specific use-case for this?

Yes, actually, any use-case in userland where async is not required or simply because the middleware reading the item(s) only acts before transport. Requiring the user to implement \Serializable when it's strictly unnecessary looks like a poor DX to me.

wouldn't it be better to have a NotSerializableEnvelopeItemInterface, so it's explicit and we keep it serializable "by default"?

It could be a solution, but TBH it feels really weird implementing an interface to opt-out from this, doesn't it?
Another solution is not considering the issue you've mentioned in the description a DX issue, but rather a documentation one and segregate properly envelope items from the notion of transport, as suggested precisely by @Koc in #26945 (comment).
If you agree, I'll merge his PR in this branch.

Requiring the user to implement \Serializable when it's strictly unnecessary looks like a poor DX to me.

That's a fair point. To me, the opt-in interface (as proposed by @Koc) makes more sense than having the isTransportable() without any kind of contract on how it is going to be transported (which is the case of the interface, because of the \Serializable). If we have too many issues caused by the subtility of some items not being serialized, then we can force it in 4.2 anyway :)

ogizanagi/symfony#1 merged

The downside of marker interfaces is that child classes cannot opt-out from them, so that such messages are totally unreusable.
From afar, forcing ppl to implement serializable may make sense to me: Messenger are for things that can pass through any bus, local or remote.
If you do not want to be able to pass through them, use event dispatcher.
Does that make sense?

The question actually is: does the message need to be aware of its "use cases". If yes, then OK. If not, then this might be considered as a leak in the abstraction. I don't have opinion on this, but we should decide.

Messages dispatchers from where are added the envelope items are aware of the use-cases, not the message. So in userland, envelope items classes would be designed according to these use-cases, and the transport is something that may or may not make sense for them...but wouldn't harm (unless sensitive data are stored in items and sent to a third-party?). The only harm is DX-wise, forcing the end-user to implement it for nothing.

Can we provide a trait instead, that implements the method by throwing?

A Non(Transportable|Serializable)Exception to be caught in SendMessageMiddleware or Serializer to ignore those items?
Could be an acceptable solution indeed.
@sroze : WDYT?

So we would provide a trait that throws a specific exception for serialize and unserialize. This exception would be caught and ignored by the Serializer (IMHO) (logged as info?). That trait could be called NonTransportableMessageTrait. I like it (much more than the serialization opt-in)

This missed an update: we cannot actually rely efficiently on an exception thrown from serialize, as we serialize the whole array of Envelope::all() items (or that would means either serializing twice or manually linearizing the array in PHP format with items already serialized separately).

So the opt-in interface would still be the way to go, but as explained above, marker interfaces have drawbacks, considering potential child classes won't be able opt-out. Perhaps not really an issue in our case (I doubt inheritance will be used extensively for envelope items nor opting-out transport for a specific child has real use-cases).
Otherwise, the first commit of this PRs (EnvelopeItemInterface::isTransportable(): bool) allows opting-out.

Either ways, we've got some time to think about it until 4.2.

Based on all these discussions, I'm now pretty much convinced that forcing the EnvelopeItem to be serializable is probably the best option.

@ogizanagi WDYT? Should we close?

Alright