Send to dead letter exchange after requeue logic reaches the number of attempts

[sblasetti]

Hi Antony, first of all thanks for creating this great library. I have a scenario to cover and I wanted to confirm whether this should be handled outside the failed message handling pipeline or if it could become a feature request.

Problem Messages are lost after handler throws an exception and the retries logic completes executing (either exhausts retries or requeue not configured in exchange).

Expectation There should be a way to do something else with the message (like sending to a DLX) after retries so the problem can be diagnosed.

Details I need the message handling pipeline to send failed messages back to the configured dead letter exchange when the message handler throws an exception and the re-queueing logic finishes with no successful handling. They currently get discarded.

In other words, when executing MessageHandlingService.HandleFailedMessageProcessing , I need the system to send the message to the DLX when either:

• The exchange is configured not to requeue failed messages (options.RequeueFailedMessages = false), or
• The exchange is configured to requeue them (options.RequeueFailedMessages = true) and reaches its retries limit (current attempt number == options.RequeueAttempts)

I want to add exception details to the message (perhaps via Headers) before sending the messages to the DLX, so people investigating the issue can read it.

I see two ways of implementing this:

1. Add a new option for the exchange to configure this behavior and update MessageHandlingService.HandleFailedMessageProcessing to send the message to the DLX when the message failed and either the exchange is not configured to retry or all retries were done.
2. Create a base non-cyclic message handler that will catch exceptions and then check for the headers similarly to how it's done in MessageHandlingService.HandleFailedMessageProcessing and finally send the message to a DLX if configured.

Both cases have drawbacks as either I'm messing with the execution pipeline code or I'm duplicating headers checking code outside the pipeline.

Questions

• Does the library already supports something like this and I'm not seeing it?
• If not, do you think that the scenario is common enough to try to come with an update to MessageHandlingService.HandleFailedMessageProcessing and a possible feature for the library?

Thanks in advance and please let me know if any clarification is required.

[antonyvorontsov]

@sblasetti Please, check out the linked PR. I hope this is what you are looking for.

If everything is okay, I will try to release a newer beta version of the library (another 5.0.0 pre-release).

Best regards, Antony

[sblasetti]

Awesome! I'll take a look.

[antonyvorontsov]

Sebastian, I published a newer version of the library (5.0.0-beta-02). You can try it out now.

Be aware that those pre-release versions of 5.0.0 contain a lot of changes and current docs are out of date. I am trying to find free time to finish documentation, but I do not have an estimate time when it will be done. So if you have questions about 5.0.0 you can contact me via email for some details. I hope I will manage to update docs soon.

Best regards, Antony