What common pitfalls should you avoid when using @Retryable?

Several mistakes are frequently made when developers first start using @Retryable. Being aware of these pitfalls saves significant debugging time.

1. Self-invocation problem
Calling a @Retryable method from within the same class bypasses the AOP proxy, and the retry logic is silently ignored:

// WRONG — retry will not fire
public void doSomething() {
    this.fetchData(); // same class, proxy is bypassed
}

@Retryable
public String fetchData() { ... }

Fix: inject the bean into itself (@Autowired ApplicationContext lookup) or move the retryable method to a separate Spring bean.

2. Retrying non-transient failures
Retrying a 400 Bad Request or a constraint violation is pointless because the same input will always produce the same error. Only transient exceptions warrant retry.

3. Not setting maxAttempts explicitly
The default is 3 attempts with no backoff delay. In production, rapid-fire retries against a struggling service can worsen the situation.

4. Missing @EnableRetry
Without @EnableRetry on a configuration class, all @Retryable annotations are ignored and no error is thrown — the method simply executes once and propagates the exception.

5. @Recover method signature mismatch
If the return type or exception parameter type does not match, Spring Retry cannot find the recovery method and will rethrow the exception instead of recovering.