Clarification around MassTransit Fault handling in Azure service bus subscriptions

Question

I just wanted to clear up my understanding with how MassTransit behaves in a scenario whereby a consumer throws an exception inside a subscriptionEndpoint, I believe this is the process:

• Message gets delivered to topic and flows into each of its subscriptions
• MassTransit obtains a lock on the message from the broker and runs the consume method
• Consumer throws an exception
• MassTransit retries in memory if consumer definition is configured with a retry policy
• Exception is eventually thrown and a Fault is raised
• This Fault message is moved to an error queue.
• The subscription message is also moved to the Dead letter queue of that subscription

What I am mostly unclear on though is that last point . Does the message get marked as consumed and removed from the broker or does it count as faulted so we will have a message in the DLQ of the Azure Topic Subscription and in the error queue?

If it does end up in the dead letter does MassTransit explicitly mark it as dead lettered so Azure Service Bus does not attempt to retry delivery to the consumer(if the retry count on the subscription was 10 for example)?

Thanks in advance

Answer 1

This Fault message is moved to an error queue.

That is incorrect, subscription endpoints do not have error queues. Only the Azure Service Bus DLQ is used. And yes, once the retries have been exhausted, the message is dead-lettered to the subscription's DLQ.

If the consumer process crashed, the message will be redelivered to MassTransit by Azure Service Bus up to the MaxDeliveryCount (default 10). Once that maximum delivery count is reached (assuming the process crashes every time), ASB will move the message to the subscription's DLQ.

When MassTransit moves the message to the DLQ, it adds headers describing the exception that occurred, the process, etc. ASB doesn't add anything.

MassTransit will only acknowledge a message once it has been successfully consumed without exception by a consumer, which will then allow ASB to remove it from the queue.

One additional clarification, which you didn't ask about, is message redelivery does not work with subscriptions since they are not addressable. If Azure ever adds a delayed redelivery feature (basically changing the visibility of the message to delay delivery), then MassTransit will support it as soon as it is available in the SDK.