MassTransit Redirect Messages from the Error Queue

Question

I'm going through a few examples using NServiceBus and I've stumbled across a feature I'm hoping ships with MassTransit (As it is a free service).

The feature is based around 'poisoned' messages.

If, due to a bug in your system, these messages cant ever be handled, and end up permanently in the error queue.

NServiceBus has a cool feature whereby, once you have corrected the bugs in your code, allows those messages in the error queue to be 'redirected' to the original working queue, to be redelivered.

This is done by using a NServiceBus specific tool :- ReturnToSourceQueue.exe.

Does MassTransit have a similar tool for this kind of issue?

Or is there another workaround availble, preferbly to work with RabbitMQ.

Answer 1

This functionality is easily recreated with nothing more than RabbitMQ and a bit of code. While it's nice that NServicebus includes it, building it with MassTransit should be easy enough.

(note: i haven't used .NET in a few years, so my knowledge of NSB and MT are a bit rusty... this will be high level answer only, no code)

The thing to start with, is a proper configuration of a dead letter exchange and a poison message queue. https://www.rabbitmq.com/dlx.html

Once you have knowledge that a message is causing errors and is a bad message, you can reject or nack (with no requeue) the message in order to send it through the dead letter exchange (DLX).

Once a message has gone through the DLX, you will have some additional properties on the message, including:

• queue - the name of the queue the message was in before it was dead-lettered,
• exchange - the exchange the message was published to (note that this will be a dead letter exchange if the message is dead lettered multiple times),
• routing-keys - the routing keys (including CC keys but excluding BCC ones) the message was published with,

there will be more, but these are the things you want to pay attention to. by examining these properties on the message, you can re-send the original message back through the original exchange, with the original routing-keys. alternatively, you can re-send straight to the original destination queue... i think sending through the exchange would be better, personally, as the original queue might not exist anymore (depending on system configuration, consumers creating exclusive queues, etc).

with this information, recreating the feature set should not be too difficult. rabbitmq provides all of the features that you need, you just have to write a bit of code to take advantage of it.