In the previous post we went through how exceptions are handled in MassTransit. By default the only mechanism is that if a registered consumer throws an exception while processing a message then that message ends up in an error queue. The error queue is named after the queue name where the consumer is listening with “_error” attached to it. By default MassTransit won’t try to relay the message again. However, it’s simple to add various retry policies with the UseRetry extension method. We can configure a wide range of retry policies: incremental, exponential, exception-based ones and other types. In addition MassTransit publishes a Fault message if all retries have been exhausted without success. The fault address or response address can specify a different queue where the fault message will be delivered. A different consumer can then monitor the fault queue and do something meaningful with the fault message.
In this post we’ll look at how message type inheritance is supported in MassTransit.
Read more of this post