Improve retry configuration validation in RetryableTopicAnnotationPro…

[Arbaz4Sayyad]

Problem

Retry configuration does not validate invalid values such as zero or negative attempts, leading to unclear error messages at runtime.

Root Cause

Missing validation logic in RetryableTopicAnnotationProcessor.

Solution

• Added validation for retry attempts in the annotation processor
• Improved error messaging for invalid configurations
• Fail fast with clear error messages

Impact

• Prevents invalid configurations before runtime
• Improves developer experience
• Makes retry behavior predictable
• Follows Spring Boot best practices for validation

Testing

• Added unit tests to validate invalid retry attempts (zero and negative values)
• Tests cover both method-level and class-level annotations
• Ensures clear error messages are provided

Example

Before: @RetryableTopic(attempts = "0") would fail with unclear error
After: @RetryableTopic(attempts = "0") fails immediately with "Retry attempts must be greater than 0, but got: 0"

[Arbaz4Sayyad]

Hi maintainers,

I’ve implemented the proposed change and added test coverage.
Could you please review and let me know if any changes are required?

Happy to update the PR based on feedback. Thanks!

[artembilan]

Hi, @Arbaz4Sayyad !

Thank you for contribution.

Execution failed for task ':spring-kafka:checkstyleTest'.
> A failure occurred while executing org.gradle.api.plugins.quality.internal.CheckstyleAction
   > Checkstyle rule violations were found. See the report at: file:///home/runner/work/spring-kafka/spring-kafka/spring-kafka/build/reports/checkstyle/test.html
     Checkstyle files with violations: 1
     Checkstyle violations by severity: [error:5]

Please, run ./gradlew check locally before pushing to this PR's branch.

[Arbaz4Sayyad]

@maintainers

Closing this PR as the retry validation feature has been incorporated into PR #4397.

The retry configuration validation improvements are now part of the checkstyle fixes PR to avoid duplicate work and streamline the review process.

Thanks for understanding!

[artembilan]

First of all don’t call maintainers GH user into our discussion. He or she is not a part of the team and mentioning that user for nothing is a bit rude from his/her perspective. I don’t think there is such a general GH handle to mention all the team members. We all see all these comments already just because we are the projects maintainers.

Closing this PR as the retry validation feature has been incorporated into PR

I don’t think this was the right decision. Those are different concerns even if they talk about the same class. And from our perspective that even make review more complicated.

please, revise your decision and concentrate on small and straightforward changes.