How to cope with this downside of MediatR?
This is a quote from Derek Comartin that describes well the issue. "One of the biggest downside to in-process processing (which MediatR does), is it does not isolate the actual handling of a request. This isn’t a problem with MediatR at all, just the nature of it executing in-process. Everything is done in-process. Meaning that wherever process is calling mediator.Send() is also the same process that is executing the relevant Handler for that request.
A notification can have zero or multiple handlers. However the execution of all the notification handlers are done all in the same process. If you publish a notification to MediatR, and there are 3 handlers for that notification, it will execute all 3. But what happens if one of them fails and throws an exception? That exception will bubble up back to where you published the message via MediatR. How do you want to handle this? Can you re-publish that message again and have the handlers that succeeded run again? What if one of them was sending an email ?"
Now my question is, other than moving to out-of-process messaging, how to cope with this disadvantage ?
2 Replies
the obvious solution is that you could stick a try/catch in each handler, or around where the handler is called, if you modify the source of the mediator
but some of those drawbacks cant be mitigated entirely, which is sort of the point
for example, there is no way to handle retrying the same message/command on SOME handlers but not on others. again, this CAN be added to each handler individually, with something like polly, but it would not be very clean
okay thanks !