Retry event handler and process manager on error

[slashdotdash]

Event handlers and process managers are expected to return :ok on successful handling of an event. They return {:error, reason} on failure. In this case the event handler should be retried.

Potential error handling options: retry, skip, ignore, stop, or park event.

[Papipo]

Maybe skipping the event is not always a viable option depending on the domain. I guess that failing is a must in many scenarios. Maybe there is a bug that has to be fixed and skipping some events leads to inconsistent state.

[slashdotdash]

@Papipo Skip event on error could be made configurable, either per event handler or globally.

[slashdotdash]

Could use tarearbol to provide retry logic.

[drozzy]

I see no need for this.

1. Crash the app.
2. App restarts as defined pre restart policy.
3. Event gets delivered again.
4. App may crash again. After erlang-defined crash semantics exceed the threshold the BEAM shuts down.
5. Upper level machinery (e.g. docker) may restart the server.

This works great for my own cases (where I hand-built my process managers). Can't see why commanded would not succeed with this simple approach as well.

[astery]

@drozzy, I think you talking about scenario when process manager generally fails (all process manager instances are failed), it's definitely should result app crash.

And I think proposal about - why crash the whole application if only one specific process manager instance fails? Just submit log, and stop executing bad process manager instance, or try another restart policy (like dropping state or skip event).

[slashdotdash]

@drozzy Providing an extension point allows consumers of Commanded finer control over how they deal with errors on a case by case basis. So you could decide that for a certain event handler, or particular event, it should retry X times with exponential back-off between retries. Another handler could simply skip any problematic events. You could do this yourself inside an event handler, I'm proposing that Commanded provides a convenient interface for you to use.

I don't know exactly what the best strategy is for each use case, therefore make it user configurable.

[drozzy]

Seems like this can be done with some external dependency in client code. Is there any actual use cases for this?

P.S.: I quite like Gregg's approach to features.

[slashdotdash]

Closing this issue. Replaced by #93 to support error handling for process manager command dispatch only.