Repository navigation
Conversation
ProfileCredentialsProvider set currentProfileFile before creating the delegate for it. Callers that skip the lock compare against currentProfileFile, so during the reload they used the previous delegate, and a reload that failed left the new file marked as loaded so later calls kept returning the previous credentials. Build the delegate first and publish the profile file afterwards. Fixes aws#7466
1 task
This branch has not been deployed
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.
Motivation and Context
Fixes #7466.
ProfileCredentialsProvider.resolveCredentials()setcurrentProfileFileto the new profile file before it built the delegate credentials provider from it. Two problems follow:shouldUpdateCredentialsProvidercheck (the file already matches), skip the lock, and resolve from the previous delegate. They get the previous file's credentials.currentProfileFilealready points at the new file. Every later call skips the reload and returns the previous file's credentials without an error.Modifications
In the synchronized block, build the delegate first and set
currentProfileFileafterwards. Both fields arevolatile, so a caller that sees the newcurrentProfileFilealso sees the new delegate. A failed reload leavescurrentProfileFileunchanged, so the next call retries and fails the same way instead of falling back to the old credentials.This does not overlap with #7435, which serializes the first initialization (#6827). The #7435 diff still applies cleanly on top of this branch.
Testing
ProfileCredentialsProviderTest#resolveCredentials_reloadedProfileFileWithoutCredentials_keepsThrowingInsteadOfReturningPreviousCredentials: the supplier switches from a file with credentials to one without. Before the fix the third call returnsakid1. After the fix it throws like the second call.resolveCredentials()together right after the supplier switches files, repeated 3,000 times. Before the fix 454 of 48,000 calls returned the previous file's credentials. After the fix, 0.mvn test -pl core/authon JDK 17: 382 tests, all pass.checkstyle:checkpasses forcore/auth.Types of changes
Checklist
mvn installsucceedsscripts/new-changescript and following the instructions. Commit the new file created by the script in.changes/next-releasewith your changes.License
This change was generated by AI tools, and reviewed by @gibkim.