As stated in the documentation,
RetryScheduler will not schedule a retry for explicitly non-transient exceptions. With the current implementation, checked exceptions are considered non-transient, but also
In command handlers, I’m using
CommandExecutionExceptions for communicating business violations to the dispatching side. Unfortunately, with the current implementation of the
AbstractRetryScheduler.isExplicitlyNonTransient() method, all my
CommandExecutionExceptions will be treated as transient, and commands will be retried.
I can handle the situation by implementing my custom extensions of
AbstractRetryScheduler. However, I found this unfortunate, as I’m trying to deal with a pretty common scenario, I believe.
I think the problem can be avoided by adding something like the
nonTransientFailures property (list of exception classes) to the
AbstractRetryScheduler and its builder. The method
isExplicitlyNonTransient() can then be modified to check if any configured non-transient exception classes are assignable from the actual failure.
In addition, for more complex cases, we can also add the
nonTransientFailurePredicate property and leave non-transient checking logic to the user.
It looks to me, with the changes above, we will significantly reduce the need for custom implementations of