can this be tested somehow?

Test added.

Should be rebased (see#51653)

Rebased.

Psalm errors fixed.

What about reverting the changes made to the now deprecatedgetNestedExceptions() to update the newly introduced API only?

What about reverting the changes made to the now deprecated getNestedExceptions() to update the newly introduced API only?

You mean throw anarray_values() intogetNestedExceptions() before returning?

Another thing, it would be nice ifDelayedMessageHandlingException (which implements this new interface) could provide handlers names as array keys as well but.. I don't think this is possible?

You mean throw an array_values() into getNestedExceptions() before returning?

It's probably not a big deal here but yes, we usually avoid changing deprecated code paths.

Another thing, it would be nice if DelayedMessageHandlingException (which implements this new interface) could provide handlers names as array keys as well but.. I don't think this is possible?

I think it would be possible to useexception->getTrace()[0]['class'] as keys inDispatchAfterCurrentBusMiddleware.
I may be missing some edge cases though e.g. if the exception wasn't thrown by the handler or if the handler callable has no class (if that's even possible?)

It's probably not a big deal here but yes, we usually avoid changing deprecated code paths.

@chalasr, I've made this change.

I think it would be possible to use exception->getTrace()[0]['class'] as keys in DispatchAfterCurrentBusMiddleware.
I may be missing some edge cases though e.g. if the exception wasn't thrown by the handler or if the handler callable has no class (if that's even possible?)

I'm going to leave this off of this PR because of the possible edge cases you describe. This can be revisited later if desired.

Thank you@kbond.