Skip to content

Publish reloaded profile file after its credentials provider is built - #7474

Open
gibkim wants to merge 1 commit into
aws:masterfrom
gibkim:fix/7466-profile-credentials-reload-order
Open

gibkim wants to merge 1 commit into
aws:masterfrom
gibkim:fix/7466-profile-credentials-reload-order

Conversation

@gibkim

@gibkim gibkim commented Oct 22, 2026

Copy link
Copy Markdown

Motivation and Context

Fixes #7466.

ProfileCredentialsProvider.resolveCredentials() set currentProfileFile to the new profile file before it built the delegate credentials provider from it. Two problems follow:

  • While one caller is building the new delegate, other callers pass the unsynchronized shouldUpdateCredentialsProvider check (the file already matches), skip the lock, and resolve from the previous delegate. They get the previous file's credentials.
  • If building the delegate throws (for example, the new file has no credentials for the profile), currentProfileFile already 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 currentProfileFile afterwards. Both fields are volatile, so a caller that sees the new currentProfileFile also sees the new delegate. A failed reload leaves currentProfileFile unchanged, 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

  • New ProfileCredentialsProviderTest#resolveCredentials_reloadedProfileFileWithoutCredentials_keepsThrowingInsteadOfReturningPreviousCredentials: the supplier switches from a file with credentials to one without. Before the fix the third call returns akid1. After the fix it throws like the second call.
  • Concurrency check, not included in the PR because it is timing-dependent: 16 threads 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/auth on JDK 17: 382 tests, all pass. checkstyle:check passes for core/auth.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed
  • I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

This change was generated by AI tools, and reviewed by @gibkim.

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ProfileCredentialsProvider: concurrent callers get the previous profile file's credentials during a reload

1 participant