This was initially discussed in #27008 (comment) and #27008 (comment). That PR is for an AMQP-specific retry mechanism but it got me thinking of a more general retry system.

I am opening this issue to discuss further.

Here are some thoughts I have on this:

1. A blanket retry could cause some issues:
   • If a message is handled by multiple handlers and only one fails it might not be desirable for it to be retried on all handlers.
   • The handler may fail at a point where retrying would not be required or desired.
2. One solution to above could be for handlers to notify the bus that a retry is required for this specific handler:

   // in your handler
   try {
       // ... some logic that throws an exception
   } catch (\Throwable $e) {
       throw new RetryException(__CLASS__, $e); // or instead of __CLASS__ we can get the class from the exception's trace? Not sure about this...
   }

   The message should then only be retried on that handler.
3. It would obviously be beneficial to provide a $maxRetry (and probably a $delay). Maybe at the handler level, maybe not...

   throw new RetryException(__CLASS__, $e, $maxRetries, $delayInSeconds);

4. The ability to record when a message fails too many times. Laravel has a feature that stores these in the database for later review and re-run.