Issue with @Retryable(retryFor) not working as expected after upgrading Spring Boot

[kuroiwa-takumi]

Description
I recently upgraded my Spring Boot project from 2.7.0 to 3.3.2, and I encountered an issue with the @Retryable annotation.
I want the method to retry only when a specific exception (TokenExpiredException.class) is thrown.
However, the method retries on all exceptions, not just the specified one.

My setup

• Spring Boot version: 3.3.2 (previously 2.7.0, where the retry mechanism worked fine)
• Spring Retry version: 2.0.6 (previously 2.0.0, where everything worked correctly)
• Java version: 17
• TokenExpiredException: This is a custom exception in my application.

public class TokenExpiredException extends RuntimeException {}

I've tried both the @Retryable(retryFor = TokenExpiredException.class) annotation and a RetryTemplate configuration, but the retry mechanism still occurs for all exceptions, not just the one I want to retry (TokenExpiredException.class).

Here is a simplified version of my code (rewritten as a sample):

RetryConfig (with RetryTemplate)

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.retry.RetryListener;
import org.springframework.retry.support.RetryTemplate;
import org.springframework.retry.support.RetryTemplateBuilder;

@Configuration
public class RetryConfig {

    private final RetryListener retryListener;

    public RetryConfig(RetryListener retryListener) {
        this.retryListener = retryListener;
    }

    @Bean
    public RetryTemplate retryTemplate() {
        return new RetryTemplateBuilder()
            .maxAttempts(3)
            .fixedBackoff(1000) // 1 second backoff
            .retryOn(TokenExpiredException.class)
            .withListener(retryListener)
            .build();
    }
}

RetryListenerImpl

import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.RetryListener;
import org.springframework.stereotype.Component;

@Component
public class RetryListenerImpl implements RetryListener {

    @Override
    public <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {
        // Custom logic when retry fails, only retry on TokenExpiredException
        if (throwable instanceof TokenExpiredException) {
            System.out.println("Retrying due to TokenExpiredException");
        }
    }
}

Service

import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;

@Service
public class CallApiService {

    @Retryable(retryFor = TokenExpiredException.class, maxAttempts = 3)
    public void callExternalApi() throws TokenExpiredException {
        // Method logic where the retry should happen
        throw new TokenExpiredException("Token expired");
    }
}

Expected behavior
The method should retry only when TokenExpiredException is thrown, not for any other exceptions.

Actual behavior
The method retries for all exceptions, even those that are not TokenExpiredException.

Additional context

• The TokenExpiredException is a custom exception in my application.
• The retry mechanism worked fine in Spring Boot 2.7.0 with Spring Retry 2.0.0.
• After upgrading to Spring Boot 3.3.2 and Spring Retry 2.0.6, this issue appeared.
• Some private business logic has been omitted or rewritten for clarity.

Steps to reproduce

1. Create a method with @Retryable(retryFor = TokenExpiredException.class) in Spring Boot 3.3.2.
2. Throw any exception other than TokenExpiredException in the method.
3. Observe that the method retries for all exceptions.

I would appreciate it if you could review the issue and provide feedback or suggestions.

[artembilan]

Any chances that you can share the whole simple project to reproduce?
Doesn't look like your callExternalApi() throws anything else, but TokenExpiredException.
Thanks

[artembilan]

Just tested with simple service like this:

	protected static class RetryableService {

		private int count = 0;

                @Retryable(retryFor = RuntimeException.class)
		public void service() throws IOException {
			if (this.count++ < 2) {
				throw new RuntimeException("Planned");
			}
			else if (this.count > 3) {
				throw new IOException("non retryable");
			}
		}

		public int getCount() {
			return this.count;
		}

	}

The output is like:

2024-09-25 12:31:10,411 TRACE org.springframework.retry.support.RetryTemplate [main] : RetryContext retrieved: [RetryContext: count=0, lastException=null, exhausted=false]
2024-09-25 12:31:10,417 DEBUG org.springframework.retry.support.RetryTemplate [main] : Retry: count=0; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,418 DEBUG org.springframework.retry.support.RetryTemplate [main] : Checking for rethrow: count=1; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,418 DEBUG org.springframework.retry.support.RetryTemplate [main] : Retry: count=1; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,418 DEBUG org.springframework.retry.support.RetryTemplate [main] : Checking for rethrow: count=2; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,418 DEBUG org.springframework.retry.support.RetryTemplate [main] : Retry: count=2; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,478 TRACE org.springframework.retry.support.RetryTemplate [main] : RetryContext retrieved: [RetryContext: count=0, lastException=null, exhausted=false]
2024-09-25 12:31:10,478 DEBUG org.springframework.retry.support.RetryTemplate [main] : Retry: count=0; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,479 DEBUG org.springframework.retry.support.RetryTemplate [main] : Checking for rethrow: count=1; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'
2024-09-25 12:31:10,479 DEBUG org.springframework.retry.support.RetryTemplate [main] : Retry failed last attempt: count=1; for: 'org.springframework.retry.annotation.EnableRetryTests$RetryableService.service'

After second RetryContext retrieved we go to the else if (this.count > 3) { branch and throw that IOException.
According to the following logs we don't see any retry on this: just re-thrown immediately.

[kuroiwa-takumi]

Thank you for your response.

In my case, the issue wasn’t related to the version after all.

Instead, I discovered that when an exception occurs in a method annotated with @Retryable, the onError method in my RetryListener implementation (RetryListenerImpl) was always being called, regardless of the exception type.

For example, even with the following setup:

@Retryable(retryFor = TokenExpiredException.class)

I observed that the onError method was triggered even when exceptions other than TokenExpiredException were thrown.

Is this expected behavior? Should the onError method in the RetryListener be called for exceptions that are not specified in the retryFor attribute?

Here is a simplified version of my RetryListenerImpl class:

import org.springframework.context.annotation.Configuration;
import org.springframework.retry.RetryCallback;
import org.springframework.retry.RetryContext;
import org.springframework.retry.RetryListener;

@Configuration
public class RetryListenerImpl implements RetryListener {

  @Override
  public <T, E extends Throwable> void onError(
      RetryContext context, RetryCallback<T, E> callback, Throwable throwable) {

    // Simplified: No business logic here
  }
}

Looking forward to your clarification on this. Thank you!

[kuroiwa-takumi]

Behavior of @Retryable

@Retryable(retryFor = TokenExpiredException.class)

• When a method annotated with @Retryable executes without any errors: No retries are performed, and the listener is not called (as expected).
• When an exception other than TokenExpiredException occurs in a method annotated with @Retryable: The onError method defined in the listener is still called.

Is this the intended behavior? If so, I am considering not including retry logic inside the onError method.

[artembilan]

OK. Thank you further clarification!
Unfortunately your orginal report has misled me.
You didn't mention that your concern is exactly about RetryListener.onError() call.

The logic there in the RetryTemplate is like this:

			try {
					if (this.logger.isDebugEnabled()) {
						this.logger.debug("Retry: count=" + context.getRetryCount() + labelMessage);
					}
					// Reset the last exception, so if we are successful
					// the close interceptors will not think we failed...
					lastException = null;
					T result = retryCallback.doWithRetry(context);
					doOnSuccessInterceptors(retryCallback, context, result);
					return result;
				}
				catch (Throwable e) {

					lastException = e;

					try {
						registerThrowable(retryPolicy, state, context, e);
					}
					catch (Exception ex) {
						throw new TerminatedRetryException("Could not register throwable", ex);
					}
					finally {
						doOnErrorInterceptors(retryCallback, context, e);
					}

					if (canRetry(retryPolicy, context) && !context.isExhaustedOnly()) {

Pay attention to two last expressions: the doOnErrorInterceptors() is called before we check for retry attempt.
Therefore the behavior your observe with your RetryListenerImpl is expected.
In fact that even mentioned in the JavaDoc:

	/**
	 * Called after every unsuccessful attempt at a retry.
	 * @param context the current {@link RetryContext}.
	 * @param callback the current {@link RetryCallback}.
	 * @param throwable the last exception that was thrown by the callback.
	 * @param <T> the return value
	 * @param <E> the exception to throw
	 */
	default <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback,
			Throwable throwable) {

Even first call for the service method is an "attempt at a retry".
I don't think it would be correct to adjust this behavior in the library someway to ignore everything for non-retryable exceptions.
We cannot assume that any other use-cases. Therefore we still provide that info back to end-user callback, and that's already up to you to make a desired decision in your code.