| name | resilience-retry |
| description | Use when adding retries, backoff, or concurrency protection to Spring Boot 3 / Spring Framework 6 services. Covers Spring Retry or Resilience4j selection, proxy behavior, and transaction limits.
|
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.
