In my team, we are trying to come up with a solution for persistence errors in our event store (MariaDB). When client sends a post and our application sends a command to command bus, there are cases where command handling fails to apply an event because of a database error. Or this might happen when Saga sends a command. When command has been sent, Axon starts a new UnitOfWork. If that command handling somehow fails to apply its event (if there is any), it would rollback that UnitOfWork and in our application event won’t be persisted, thus our application will act like that command has never been sent. So that would cause an inconsistency in our application, especially when it happens in Saga. We are planning to introduce a IntervalRetryScheduler for our application’s UnitOfWork for command handling failures. We are currently not using a retry scheduler. Is there something that I am missing in my Saga case assumption? Would introducing an interval retry scheduler would be the best course of action to handling command handling errors?
errors from Command handling are definitely not messages to simply ignore. When there’s a user on the sending end of the command, it’s easy to just forward the error to the UI, but even then, you don’t want to rely on the user to report the error.
The best thing to do by default, in my opinion, is to log the errors in such a way, that you can dispatch the command again once the ‘issue’ has been fixed. Whenever possible, in a Saga, you probably also want to automate the reaction to an error. Sagas automate a process. Errors are part of that process, too, to they also need to be automated. A retry scheduler may help with certain transient errors, but will not help if the error persists. In that case, you want to fall back to logging to enable ‘manual’ resolution.