This is ready! And it worksawesome. Here are some technical notes:

1. SendersLocatorInterface changed... because for the first time, we need to look up the sender with more logic than just the message class - we need to look up by a specific alias name

2. Sender aliases are still optional... but the system is increasingly dependent on them being available - retry, failure transport, etc.

Ready again!

Thanks for the review@chalasr!

This is once again ready to go!

Comment addressed!

Test failures are unrelated. Ready for review!

Thank you@weaverryan.

If I see it correctly, the messenger:failed:show command cannot show messages when rabbitmq is used as a failed transport because it does not implement the listing and getting individual messages.
But in theory that could still be possible by consuming all messages and then putting them back into the queue. Was that considered?

Hi@Tobion!

Yes, it’s something i talked about with Sam, but wasn’t ultimately sure about. The problem is if there aremany messages. Consuming them all, just to list them and put them back could be a big operation. I don’t have any experience in how rabbit behaves in this way. I’d love to hear any experiences related to this.

Another consideration is that (from feedback I’ve heard) people could theoretically have many failed messages (due to a 3rd party service failure, for example) and want to retry all of them, or maybe all failed messages within a date range. Retrying all of them would work fine, but doing it by date range would require the “consume all” strategy.

Finally, one other unrelated thing from feedback: retry should perhaps just requeue. This is especially important if we offer some sort of “bulk” retry/requeue: requeuing them and allowing their (potentially many) workers on the original queue do their work normally makes more sense then retrying them one-by-one of the server where someone is manually looking at and retrying the failed messages.

Also, generally speaking, I’m not sure if Amqp is a good candidate for the failure transport. The failure transport could get “large” - even in a normal app - if you rarely check it and handle those messages. That could hurt Amqp performance - it doesn’t (as I understand it) like to have queues with many messages.

Hey@weaverryan. I love this feature.I think if we provide a way to configure the failed storage, then we should also try our best to make them all feature complete.

The problem is if there are many messages. Consuming them all, just to list them and put them back could be a big operation.

I don't think it's very common to have many failed messages after retry. But as a sanity check, we could just do the listing if the amount of messages is below a threshold and ask for confirmation if not.

retry should perhaps just requeue

There are use-cases for both approaches in my opinion. You either just want to retry one and see if it works now or why it doesn't work. Or the queue is full and you don't want to wait.
But requeing also makes sense when there are too many messages and you want to leverage your workers.
So ideally both solutions would be offered.

I'm going to work on a PR for the requeue. When I've open that, let's continue discussing there to make sure we're happy with everything. I also like the "retry" for at least some situations (just retry it right now and show me if it worked!).