Masstransit retry selected how to#
Masstransit retry selected code#
Masstransit retry selected windows#

Masstransit retry selected how to#

In this post, we’ve done a walk through of how to configure MassTransit to dead letter an invalid message using FluentValidation and MediatR Pipeline Behaviours. Although it’s not technically the formal Service Bus dead letter queue, the message is now in error state and won’t be retried so it has the same effect: MassTransit error queue created and message dead-lettered Conclusion When the message is received, we get a ValidationException thrown by the RequestValidationBehaviour to say that the BookingId can’t be empty: FluentValidation ValidationException thrownĪfter this, we can see that MassTransit creates a new booking-created_error queue if it didn’t already exist and then we find our message enters that queue.

Masstransit retry selected windows#

'operatingSystemVersion': 'Microsoft Windows NT 0.0' 'urn:message:Contracts.Messages:BookingEventBase' 'urn:message:Contracts.Messages:BookingCreated', 'sourceAddress': 'sb:///M圜omputer_WebBffApi_bus_p1toyynperccyegsbdpfep7bdo?autodelete=300', It’s simply checking that the BookingId is 4 characters long: We can then make a validator for the MakeCarBookingCommand as below. Carrying on from where we left off in Part 1, we are receiving the BookingCreated message and then using MediatR to send a MakeCarBookingCommand which is received by our MakeCarBookingCommandHandler. How to configure MassTransit and MediatR to dead letter invalid messages Add FluentValidation validatorįirst, we need to add the FluentValidation package. It’s essentially the decorator pattern for handlers. If you want, you could have multiple Pipeline Behaviours so you could have one for logging also.

Masstransit retry selected code#

These Pipeline Behaviours get executed before a MediatR Request or Notification is processed by the handler so that means you can separate out that code from the actual handler so you have cleaner code and less going on in the handlers. Rather than putting guard clauses or some other form of validation logic in the MediatR handlers, we can use MediatR Pipeline Behaviours. FluentValidation also enables you to have validators in different files and you can register them in your IoC container and inject them where needed. It’s far better than lots of if.else statements.

FluentValidationįluentValidation is a great library that helps you write validations which are easy to read and modify. You can find out more about this feature here. we can configure it to not retry in case of a particular exception and this is exactly what we’re going to do – we’re going to throw a ValidationException and configure MassTransit to not retry. One thing that MassTransit enables is ignoring particular exceptions – i.e. MassTransit error handlingĪs we saw in the last post, we can configure the retries when there is an exception thrown when handling a message. Let’s talk through these and how they fit in this solution. MassTransit and MediatR and FluentValidation

If you missed it, you can go back to that post here. In part 1 of MassTransit and MediatR, we looked at the initial set up and in part 2, we looked at how we can configure MassTransit to do exponential retries when working with Service Bus. We’ll use MediatR pipeline behaviours, FluentValidation and MassTransit so it’ll be an interesting post. With Service Bus, MassTransit won’t technically dead letter an invalid message but we can get it to move it to an error queue which has the same effect.

We may receive a message and it’s invalid but we don’t want to just throw an exception and retry the message till all the retries are exhausted as the message will never be processed. In this post, we’ll look at how we can get MassTransit to dead letter invalid messages.