Retry Logic Documentation

[iberodev]

Is there any built-in retry logic?
I am looking for simple mediators where I can publish an event and have multiple subscribers consuming it, and MicroBus seems like a perfect fit for it, so thank you.

But I am exploring scenarios where it would be good to have some kind of retry logic. For example if I have one event A that is supposed to arrive after another event B but for whatever reason in microbus the event B is placed before event A, therefore I could throw an exception when handling event B (because A hasn't been processed yet) and hope to have some retry logic built in with MicroBus so that in the next attempts it eventually succeeds.

If this is a scenario where I could use MicroBus, could you please point me to the right place to explore it? Thanks

[daniellittledev]

There is no built in retry logic in Microbus but it would be something you can add using a global IDelegatingHandler and something like https://github.com/App-vNext/Polly

[diegosasw]

Interesting question.
I guess it also depends on whether multiple event handlers (or message handlers) run in parallel or sequentially. How does MicroBus work?
If a publisher publishes in the mediator EventA and EventB on that order, and there are 2 handlers registered EventAHandler and EventBHandler,

1. is there any chance EventBHandler runs before EventAHandler?
2. if EventAHandler throws some exception or there is some retry logic, does EventBHandler execute? or is it sequential?

Depending on this, the original question would make more sense or not.

PS: I had a look at MediatR and it seems they don't guarantee the order in which the handlers are executed but not sure either if the handlers run in parallel or sequentially.

[daniellittledev]

In MicroBus you can choose to run handlers as asynchronous or asynchronous see Bus Settings.

Regarding retries in Delegating handlers they would cause all Event Handlers to re-run (or to be more precise, all handlers below them). So if say the first handler completed and the second handler failed both would run again. In this case you must ensure the transaction spans both handlers and plays nicely with retries. If there is no transaction you could also ensure each handler is idempotent so they can be run multiple times.

MicroBus does nothing to guarantee the order in which handlers are run but It's likely they will always run in registration order.