I have created a POC retry system with just a few extension points added to the framework. I understand that how retries work can be very opinionated. My sample flex app is here with the specific changes from an out of the box flex website-skeleton here.

Some notes on how the app's bus works:

• If any exception is thrown in a handler, the exception is wrapped in a FailedMessageException which contains the context of the exception: message, wrapped exception, single handler id. (see WrapExceptionHandleMessageMiddleware and CatchExceptionChainHandler)
• These failed messages are caught and saved. They are just logged for now but could be saved to a database for later rerun. (see SaveFailedMessageMiddleware)
• These failed messages can be rerun on just the handler they failed using a SingleHandlerConfiguration which takes the saved "single handler id" from the FailedMessageException above. (see SingleHandlerMiddleware)
• Added a RetryMessageException which can be thrown from your handlers with a max attempt and delay. These failed messages are retried x times before failing fully and saved with SaveFailedMessageMiddleware above. (see RetryMessageMiddleware for the retry mechanism and FileTransport for the delay)

In order to make this work, I had to make 3 changes to Symfony:

1. kbond@be52d56: This changes the custom handler method service IDs to be class::method. This allows (2) below to work. As an added benefit, the debug:messenger command is improved. See the output of a custom handler method without this change:

    ------------------------------------------------------------ 
     App\Event\BarEvent                                          
         handled by App\Event\BarEventSubscriber                 
     App\Event\FooEvent                                          
         handled by App\Event\FooEventSubscriber1                
         handled by .messenger.method_on_object_wrapper.Bb2WIx8  
         handled by App\Event\FooEventSubscriber3                
    ------------------------------------------------------------
   

   And after:

    ----------------------------------------------------- 
     App\Event\BarEvent                                   
         handled by App\Event\BarEventSubscriber          
     App\Event\FooEvent                                   
         handled by App\Event\FooEventSubscriber1         
         handled by App\Event\FooEventSubscriber2::doFoo  
         handled by App\Event\FooEventSubscriber3         
    -----------------------------------------------------
   

2. kbond@7af9dc0: This adds an optional ContainerSingleHandlerLocator service that allows you to resolve a single handler. This is needed for the SingleHandlerMiddleware in my POC above.
3. kbond@3a46d1a: This allows you to configure your own ChainHandler. Currently, if the chain handler is handling multiple messages and one fails, all subsequent messages are not run. I wanted to ensure this wasn't the case. I also use it to aggregate FailedMessageException's into a ChainFailedMessageException

Anyway, this scope of this issue has grown pretty large but I just wanted to share a possible use-case I see for the component and where the the blockers are in Symfony.

Ideally, I'd like to see FailedMessageException, ChainFailedMessageException, SingleHandlerMiddleware and CatchExceptionChainHandler (perhaps as the default thus not needing configuring) in core.

Of course, for synchronous message buses you would want the actual exception thrown - this could be done with a default middleware that unwraps the FailedMessageException.

This is still a thing as it is currently not possible to built a retry mechanism that takes into account that just one of many handlers had failed and on redelivery just the failed handlers should be called again.
One way to dramatically improve this would be to change the HandleMessageMiddleware in two ways

1. try all registered handlers for each message and catch Exceptions from handlers. Throw a Exception which has a collection of all occured Exceptions like the ChainFailedMessageException described here. This has the advantage that one failing handler won't stop the whole execution chain.

2. don't run handlers multiple times on same message. Just check the handled stamp on the envelope if the message was already handled by the handler, then skip it.

Combined this would lead to the possibility of just redelivering the message by dispatching the modified envelope, what can be easily achieved with a custom middleware. IMHO this redelivering mechanism is not necessarily part of the Framework, because it will depend on custom circumstances, like if the used transport already brings an redelivering mechanism, or if the redelivering should be delayed, etc. But in general it should be possible to build a solid retry mechanism.

Let me know what you think, i'll happilly prepare a PR for this one.

Closing in favor of #30557 and also #30020