resilience-retry

Resilience and Retry (Boot 3)

Boot 3 does not have Spring Framework 7 core resilience annotations. Choose Spring Retry for simple imperative retry or Resilience4j when you also need circuit breakers, rate limiting, or bulkheads. Keep the dependency and configuration explicit.

@Configuration
@EnableRetry
class RetryConfig { }

@Service
class PaymentClient {
    @Retryable(
        retryFor = ConnectException.class,
        maxAttempts = 4,
        backoff = @Backoff(delay = 200, multiplier = 2.0, maxDelay = 2000))
    PaymentResult charge(ChargeRequest request) { ... }

    @Recover
    PaymentResult recover(ConnectException error, ChargeRequest request) { ... }
}

Spring Retry's maxAttempts includes the initial call. Resilience4j is preferable when retry must be composed with a circuit breaker or bulkhead. Both approaches are proxy-based: self invocation bypasses advice, and retrying a method inside a rollback-only transaction does not create a fresh transaction for each attempt.

Gotchas

• Agent uses Framework 7 @EnableResilientMethods - Boot 3 needs Spring Retry or Resilience4j.
• Agent confuses maxAttempts with retry count - Spring Retry includes the initial call.
• Agent adds @Recover to Resilience4j - recovery must be modeled with a fallback or caller handling.
• Agent retries a self-invoked method - call through a Spring proxy.
• Agent retries inside a transaction expecting a fresh transaction - move retry outside the transactional bean.
• Agent retries non-idempotent writes without an idempotency key - protect payment and command operations.