[IMPROVEMENT] withRetries should not affect other calls #75

Activity

1. pcsiszar-bw

   added

   enhancementNew feature or requestNew feature or request

   on Feb 16, 2026
2. henryx

   added

   next-major-versionIssue can be made in the next major versionIssue can be made in the next major version

   on Oct 6, 2026
3. henryx

   added this to the 7.0.0 milestone on Oct 8, 2026
4. henryx commented on Oct 15, 2026

   

   henryx

   on Oct 15, 2026

   Collaborator

   More actions

   Thanks for the report. The next release lets you set retries for a single call without changing the
   configuration, through a new method rather than by changing withRetries().

   Retries for some calls: Vault.retrying()

   final LogicalResponse response = vault.retrying(5, 1000)
                                         .logical()
                                         .read("secret/hello");

   retrying() returns a new Vault whose operations use those retries. The original vault
   and its VaultConfig are left unchanged, so later calls on vault are not affected. The retry
   settings are held in a new immutable RetryPolicy and passed to Logical, Auth, Sys and the
   other operation classes, including the ones they create (e.g. sys().leases()).

   Retries for every call: VaultConfig.retries()

   final VaultConfig config = new VaultConfig()
                                     .address("http://127.0.0.1:8200")
                                     .token("...")
                                     .retries(5, 1000)
                                     .build();

   Both methods reject negative values with IllegalArgumentException.

   Why withRetries() is deprecated rather than changed

   Changing what withRetries() does would break existing code without any compile error. Code like
   this:

   vault.withRetries(5, 1000);
   vault.logical().read("secret/hello");

   would still compile, but would silently stop retrying. That would only show up during a Vault
   outage, which is exactly when retries matter. So withRetries() keeps its current behaviour and is
   now @Deprecated, with Javadoc pointing to retrying() and VaultConfig.retries().

   Why the configuration is shared rather than copied

   The issue suggested passing a copy of VaultConfig with the retry settings. Instead, the Vault
   returned by retrying() shares the original configuration and keeps the retries separately. A copy
   would miss later changes, such as a renewed token, and its HTTP client and SslConfig would need
   special handling. Sharing the configuration keeps it unchanged while still applying those later
   changes.

   What's left

   Removing withRetries(), or making it return a new instance like retrying(), is a breaking
   change, so it is planned for the next major release and tracked in #.

   Closing this, since retries can now be limited to some calls without changing the configuration.
5. henryx

   closed this as completedin #80on Oct 15, 2026