[Feature request] Add a way to choose between different behaviors depending on the exception

[stof]

In my current project, I want to retry the message for some errors (temporary failure of the SMTP server for instance), while some other errors should never be retried (malformed message which cannot be handled by my application at all for instance, and would just fail again when retrying). IT would be great to provide a way to achieve this (it might be done as a documentation page though if it requires too much custom logic to be added in existing processors)

[stof]

this applies both to the RetryProcessor and InstantRetryProcessor (skipping the retry) and to the AckProcessor (choosing to requeue or no).

[odolbeau]

Why do you want to throw exception if you know you don't want to do anything if they happen?
Catching & log them could be enough I guess?

It's basically what I usually do when I have an malformed message.

[stof]

@odolbeau shouldn't the message be nacked (without requeuing) in case it is malformed rather than being acked ?

[odolbeau]

It depends. By malformed message I mean a message which do not contains the "expected" information. In a lot of our workers, and for certain messages, it can happen and in this case, we ack because we consider we don't have anything to do BUT the message is relevant.

When the message is really malformed (like malformed json) we throw an exception and, you're right, the message go to a retry queue for... nothing!

In fact, apart from using a custom RetryProcessor, I don't see how we can deal with such cases in Swarrot.
The easiest solution is probably to have a special exception but could be tricky. In your case you don't want some exceptions to be re-published. Maybe in another case the goal will be to re-published only some exceptions?

Do you see a way to deal with this different use cases?

[joelwurtz]

We handled this use case by creating a separate queue and putting message in there.

To distinguish the error over other one, like a connection failure for a temporary time, we use different interface for our exception :

• RetryExceptionInterface
• CriticalExceptionInterface
• ....

So the processor will only catch this exception interface and do not bother for other ones, maybe it's something which can be added to the current processor of swarrot (but this will be BC).

For keeping BC the other option is to inject the kind of exception class you want to intercept in RetryProcessor and InstantRetryProcessor and use \Exception as a default.

[odolbeau]

Maybe it's possible to avoid BC with an implementation lie this one? #139