Class RetryingErrorHandler

java.lang.Object
io.fluxzero.sdk.tracking.RetryingErrorHandler
All Implemented Interfaces:
ErrorHandler
Direct Known Subclasses:
ForeverRetryingErrorHandler
public class RetryingErrorHandler extends Object implements ErrorHandler
An ErrorHandler implementation that retries failed operations a configurable number of times, with optional propagation or suppression of unrecoverable errors.

This handler is designed for scenarios where transient failures (e.g., network hiccups, temporary service downtime) are expected and recovery is possible through retrying the operation. It allows for detailed control over:

  • Which errors should trigger retries (via errorFilter)
  • How many retries to perform and at what delay (via RetryConfiguration)
  • Whether to stop the consumer or continue on final failure
  • Whether functional errors should be logged

Start with the default LoggingErrorHandler; opt into retries for recoverable failures with idempotent effects. The no-argument policy retries up to five times, then returns the original error and lets tracking continue. The first retry is immediate; later attempts have a two-second delay. An initial FunctionalException is excluded by default. The initial filter is not reapplied to later failures; RetryConfiguration's separate error test controls failures during retries.

Warning: with stopConsumerOnFailure = true, an exhausted or excluded failure can stop the affected tracker until explicit restart, just like ThrowingErrorHandler. Other trackers may continue. Retrying holds up progress on the affected tracker/batch and does not roll back already completed effects.

Retry Logic:

  • If the error matches errorFilter, the retryFunction is invoked repeatedly up to maxRetries.
  • If all retries fail:
    • And stopConsumerOnFailure is true, the original error is rethrown, halting tracking.
    • Otherwise, the error is logged and passed through the configured RetryConfiguration error mapper.
  • If the error does not match the filter, no retries are performed and the handler either continues or propagates, based on configuration.

Logging Behavior:

  • Technical errors are logged at ERROR level.
  • FunctionalExceptions are logged at WARN level, if logFunctionalErrors is true.
  • Retry success is logged via RetryConfiguration.successLogger.

Usage Example: 

@Consumer(name = "resilientHandler", errorHandler = RetryingErrorHandler.class)
public class ResilientCommandHandler {
    @HandleCommand
    void handle(PlaceOrder command) {
        // Retries on technical failures before giving up
    }
}
See Also:

  • Constructor Details

    • RetryingErrorHandler

      protected RetryingErrorHandler(Predicate<Throwable> errorFilter, boolean stopConsumerOnFailure, boolean logFunctionalErrors, RetryConfiguration retryConfiguration)

    • RetryingErrorHandler

      public RetryingErrorHandler()
      Constructs a handler that retries on technical exceptions up to 5 times, immediately first and with a 2-second delay after failed retries. The consumer is not stopped on failure.

    • RetryingErrorHandler

      public RetryingErrorHandler(boolean stopConsumerOnFailure)
      Constructs a handler with default retry behavior and optional consumer stop behavior.

    • RetryingErrorHandler

      public RetryingErrorHandler(Predicate<Throwable> errorFilter)
      Constructs a handler with a custom error filter that allows message tracking to continue if the error persists after retries.

    • RetryingErrorHandler

      public RetryingErrorHandler(Predicate<Throwable> errorFilter, boolean stopConsumerOnFailure)
      Constructs a handler with a custom error filter and optional consumer stop behavior.

    • RetryingErrorHandler

      public RetryingErrorHandler(int maxRetries, Duration delay, Predicate<Throwable> errorFilter, boolean stopConsumerOnFailure, boolean logFunctionalErrors)
      Constructs a handler with detailed retry configuration options.

    • RetryingErrorHandler

      public RetryingErrorHandler(int maxRetries, Duration delay, Predicate<Throwable> errorFilter, boolean stopConsumerOnFailure, boolean logFunctionalErrors, Function<Throwable, ?> errorMapper)
      Constructs a fully customized retrying handler with retry behavior and error mapping logic.

  • Method Details

    • handleError

      public Object handleError(Throwable error, String errorMessage, Callable<?> retryFunction)
      Handles the error by retrying the operation if allowed, or propagating/logging based on configuration. Throws the original error if retries are exhausted and the tracker should stop.
      Specified by:
      handleError in interface ErrorHandler
      Parameters:
      error - the encountered Throwable
      errorMessage - context about the failure
      retryFunction - the operation that failed
      Returns:
      the final result or error after retries

    • logError

      protected void logError(String message, Throwable error)
      Logs the error at the appropriate level based on its type.

    • isTechnicalError

      protected static boolean isTechnicalError(Throwable error)
      Determines if the error is a technical exception (not FunctionalException).