Skip to content

Replace Spring Retry usage to core retry #4059

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

snicoll
Copy link
Member

@snicoll snicoll commented Aug 22, 2025

This commit replaces Spring Retry by the core retry support introduced in Spring Framework 7. This is a breaking change mostly in configuration that is detailed below.

The main feature in Spring Kafka is BackOffValuesGenerator that generates the required BackOff values upfront. These are then managed by the listener infrastructure and Spring Retry is no longer involved.

Moving this code from BackOffPolicy to BackOff dramatically simplifies that class as Spring Framework's core API naturally provides this information without the need of an extra infrastructure.

From a configuration standpoint, Spring Kafka relies quite heavily on Spring Retry's @Backoff. As there is no equivalent, the annotation has been moved to Spring Kafka proper with the following improvements:

  • Harmonized name (@BackOff instead of @Backoff).
  • Revisited Javadoc.
  • Support for expression evaluation and java.util.Duration format.

The creation of a BackOff instance from the annotation is now isolated in BackOffFactory and the relevant tests have been added. RetryTopicConfigurationBuilder is mostly backward-compatible but uniformRandomBackoff has been deprecated as we feel that its name does not convey what it actually does.

RetryingDeserializer no longer offer a RecoveryCallback but an equivalent function that takes RetryException as an input. This contains the exceptions thrown as well as the number of retry attempts.

The use of BinaryExceptionClassifier has been replaced by the newly introduced ExceptionMatcher that is a copy of the original algorithm with a polished API.

With the migration done, we believe that further improvements can be made here: @BackOff oddly looks like Spring Framework's @Retryable. As a matter of a fact, the maxAttempts and includes/excludes from @RetryableTopic are touching the same concepts. One option would be to open up @Retryable so that it can be used in more case.

Another area of improvement is that harmonization of BackOff as a term. It is named "Backoff" in several places, including in @RetryableTopic, and it would be nice if the concept had the same syntax everywhere.

With Spring Retry being completely removed, this commit also removes the dependency and any further references to it.

This commit replaces Spring Retry by the core retry support introduced
in Spring Framework 7. This is a breaking change mostly in configuration
that is detailed below.

The main feature in Spring Kafka is BackOffValuesGenerator that
generates the required BackOff values upfront. These are then managed by
the listener infrastructure and Spring Retry is no longer involved.

Moving this code from BackOffPolicy to BackOff dramatically simplifies
that class as Spring Framework's core API naturally provides this
information without the need of an extra infrastructure.

From a configuration standpoint, Spring Kafka relies quite heavily on
Spring Retry's `@Backoff`. As there is no equivalent, the annotation has
been moved to Spring Kafka proper with the following improvements:

* Harmonized name (`@BackOff` instead of `@Backoff`).
* Revisited Javadoc.
* Support for expression evaluation and `java.util.Duration` format.

The creation of a `BackOff` instance from the annotation is now
isolated in `BackOffFactory` and the relevant tests have been added.
`RetryTopicConfigurationBuilder` is mostly backward-compatible but
`uniformRandomBackoff` has been deprecated as we feel that its name
does not convey what it actually does.

`RetryingDeserializer` no longer offer a `RecoveryCallback` but an
equivalent function that takes `RetryException` as an input. This
contains the exceptions thrown as well as the number of retry
attempts.

The use of BinaryExceptionClassifier has been replaced by the newly
introduced `ExceptionMatcher` that is a copy of the original
algorithm with a polished API.

With the migration done, we believe that further improvements can be
made here: `@BackOff` oddly looks like Spring Framework's `@Retryable`.
As a matter of a fact, the `maxAttempts` and `includes`/`excludes` from
`@RetryableTopic` are touching the same concepts. One option would be to
open up `@Retryable` so that it can be used in more case.

Another area of improvement is that harmonization of BackOff as a term.
It is named "Backoff" in several places, including in `@RetryableTopic`,
and it would be nice if the concept had the same syntax everywhere.

With Spring Retry being completely removed, this commit also removes the
dependency and any further references to it.

Signed-off-by: Stéphane Nicoll <[email protected]>
@snicoll
Copy link
Member Author

snicoll commented Aug 23, 2025

I've just noticed the samples are broken, sample-04 in particular. Not sure how to deal with this given that it doesn't use the snapshot atm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant