GCI604 [Team ELAN][2025] - Changelog add rule

[zizou-ben]

No description provided.

[MP-Aubay]

Hi @zizou-ben , thank you for this interesting rule.
I wonder if using a max timeout value is relevant, and how to determine the right value ...
But I think it could be a good practice to always add retryFor argument to avoid retry on a FileNotFoundException or others like this one.

Do not forget to update CHANGELOG.md and RULES.md files !

[zizou-ben]

Hello,
Thank you for your reply. Interesting point points you brought up, a max timeout in this is absolutely necessary considering that the max delay for a retryable with (max retry 3,delay:10, multiplier 100) consumes more than a retryable with (max retry 6, delay 10,and no multiplier) as we can see depending on the values of all three parameters (or lack there of) the max timeout can grow exponentially, and the only way to estimate is to calculate the result. We have configured a value for maxtimeout doing some research on existing apps ( our rule can be later improved to make this value configurable.
For your second point I am not sure I understand what you mean by retry for.
And lastly for the changelog i guess we have to do it manually not using out commit messages
Thank you for your help

[Copilot]

Pull Request Overview

This PR introduces a new rule (GCI604) to enforce a maximum retry timeout for Spring Retry and updates the changelog accordingly.

• Added Asciidoc documentation detailing the rule’s rationale, examples, and threshold
• Added JSON metadata for the new rule
• Updated CHANGELOG with an Unreleased entry for GCI604

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/main/rules/GCI604/java/GCI604.asciidoc	Documentation for GCI604 explaining inconsistent retry configuration
src/main/rules/GCI604/GCI604.json	JSON metadata for rule GCI604
CHANGELOG.md	Added Unreleased changelog entry for rule GCI604

Comments suppressed due to low confidence (4)

src/main/rules/GCI604/java/GCI604.asciidoc:1

• The first line duplicates the document title; consider removing it or converting it into a proper Asciidoc heading (e.g., prefixing with =) to avoid redundancy.

Spring Retry: Inconsistent configuration

src/main/rules/GCI604/GCI604.json:2

• The JSON title is too generic and doesn't match the Asciidoc title; consider updating it to 'Inconsistent Spring Retry Configuration' or another descriptive name.

  "title": "limit retry",

src/main/rules/GCI604/GCI604.json:1

• The rule metadata lacks a configurable parameter for max.timeout; add a properties section defining this parameter with a default value and description.

{

CHANGELOG.md:11

• There's a duplicated ## [Unreleased] header in the changelog; remove the redundant section to keep a single Unreleased block.

## [Unreleased]

[dedece35]

not only for spring-boot but also for "spring"

[dedece35]

could you please add some references like :

• https://medium.com/@adriancanton/spring-retry-implementing-retries-in-your-spring-boot-applications-43dd4c52f93f
• https://dzone.com/articles/implementing-exponential-backoff-with-spring-retry

if we respect our process for a new rule ... we have to give evidence to prove that its a good idea like :

• web documentation
• performance tests (on web documentation or local benchmark)
• link on the rule idea inside green-code-initiative : I think this is this one, isn't it ? [WEB][42108] Spring Retry: Inconsistent configuration creedengo-challenge#78

[dedece35]

maybe give some other compliant examples with acceptable "multiplier" or the "maxDelay" given to limit the maximum timeout
because we can have a relevant use case that the multiplier is relevant (for example, call an external URL to limit de spend of too much call tokens) ... but I agree, we have to control it not to consume a lot of resources.

[dedece35]

please change the title to something more explicit

[dedece35]

what is the good value for max timeout ? maybe also describe de "maxDelay" parameter

[dedece35]

Hi @zizou-ben,

after checking some web documentation, this rule is a good idea but there is a lack on some subjects like explained here https://www.baeldung.com/spring-retry
We can use "Retryable" system with different ways :

• @retryable : ok, you dealt with it
• Spring Properties
• RetryTemplate system
  Maybe can we these lacked subjects inside another PR ?

[github-actions]

This PR has been automatically marked as stale because it has no activity for 60 days.
Please add a comment if you want to keep the issue open. Thank you for your contributions!