Repository navigation
fix(token-client): retry on network errors across plain + Spring clients (4.3.1) - #2068
Merged
Merged
Conversation
DefaultOAuth2TokenService and DefaultOAuth2TokenKeyService retried only on configured HTTP status codes. An IOException from the HTTP client (connection reset, read timeout, TLS handshake error) was rethrown immediately, so transient network failures were never retried even with retry enabled (surfaced as 'Error retrieving token keys: null' during short XSUAA/IAS blips). Retry on IOException as well, bounded by the existing maxRetryAttempts and retryDelayTime. OAuth2ServiceException (an already-decided HTTP outcome) is still not retried. This matches the documented retry behavior for network errors. Prepare release 4.3.1 (version bump + changelog).
…twork errors Extend the network-error retry fix to every retrying HTTP caller so the behavior is consistent across the plain and Spring clients: - DefaultOidcConfigurationService (token-client): retry on IOException, like DefaultOAuth2TokenService/DefaultOAuth2TokenKeyService. - XsuaaOAuth2TokenService, SpringOAuth2TokenKeyService, SpringOidcConfigurationService (token-client-spring + token-client-spring-3): retry on ResourceAccessException (network errors), and route retryable HttpStatusCodeException through the same retry handling so configured retryStatusCodes take effect even though RestTemplate surfaces non-2xx as exceptions. All bounded by the existing maxRetryAttempts/retryDelayTime; OAuth2ServiceException is never retried. Adds network-error retry tests to all six services (token-client + both Spring modules). Updates CHANGELOG 4.3.1.
NiklasHerrmann21
changed the title
kuntzed
previously approved these changes
Nov 6, 2026
…ve information into log files' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com> Signed-off-by: NiklasHerrmann21 <niklas.herrmann01@sap.com>
…ve information into log files' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com> Signed-off-by: NiklasHerrmann21 <niklas.herrmann01@sap.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
kuntzed
approved these changes
Nov 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Make the token-client retry feature act on network errors, not only on configured HTTP status codes — consistently across the plain client and both Spring variants.
Reported via DINC (Jonas): the retry docs promise retries on "network issues, such as timeouts or connection errors", but the retry only fired on status codes. A timeout / connection reset / TLS error was thrown before any status code existed and was rethrown with no retry — surfacing as
Error retrieving token keys: nullduring short XSUAA/IAS blips, even withretryEnabled=trueandmaxRetryAttemptsset.A follow-up review showed the same gap existed in every retrying HTTP caller, including the Spring variants, so this PR covers all of them.
Changes
token-client (plain, retry on
IOException):DefaultOAuth2TokenServiceDefaultOAuth2TokenKeyServiceDefaultOidcConfigurationServicetoken-client-spring + token-client-spring-3 (retry on
ResourceAccessException):XsuaaOAuth2TokenServiceSpringOAuth2TokenKeyServiceSpringOidcConfigurationServiceAll retries bounded by the existing
maxRetryAttempts/retryDelayTime.OAuth2ServiceException(an already-decided HTTP outcome) is still never retried.Spring variants additionally route retryable
HttpStatusCodeExceptionthrough the same retry handling, so the configuredretryStatusCodesnow actually take effect even thoughRestTemplatesurfaces non-2xx responses as exceptions.Tests
Added network-error retry tests (then-success, retry-until-max-then-throw) to all six services across the three modules. Full suites green:
DefaultOAuth2TokenKeyServiceTest16,DefaultOAuth2TokenServiceTest20,DefaultOidcConfigurationServiceTest15SpringOAuth2TokenKeyServiceTest16,XsuaaOAuth2TokenServiceTest18,SpringOidcConfigurationServiceTest14 (each)Note
A larger retry rework (resilience4j) is planned separately and would supersede this hand-rolled loop; this is the targeted fix so the behavior matches the docs now.
Prepares release 4.3.1 (version bump across all modules + CHANGELOG).