Skip to content

Conversation

@L-Applin
Copy link
Contributor

@L-Applin L-Applin commented Dec 20, 2022

Motivation and Context

Required as part of the async IMDS Client. The async client also needs to cache the token and reuse it if it is not expired on subsequent requests.

Modifications

Added AsyncTokenCache class, caching the token and returning a CompletableFuture.
Removed TokenCacheStrategy.
Moved some async HTTP request logic to an helper class.
Added log + javadoc.

Testing

Update async unit test to make them slightly more robust.

Screenshots (if appropriate)

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

@L-Applin L-Applin changed the title Olapplin/imds async token [IMDS] Token cache for Async client Jan 3, 2023
@L-Applin L-Applin marked this pull request as ready for review January 4, 2023 16:36
@L-Applin L-Applin requested a review from a team as a code owner January 4, 2023 16:36
waitingFutures.add(result);
} else {
CompletableFuture<Token> tokenRequest = startRefresh(result);
CompletableFutureUtils.forwardExceptionTo(result, tokenRequest);
Copy link
Contributor

@millems millems Jan 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't want this. A cancellation of the result future probably shouldn't fail the refresh that's happening in the background, because other (unrelated) calls might be waiting on that refresh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean. I think it's fine to remove it because we will still cancel the request made with the token after, it's only the token refresh call that would be not be cancellable by the users.

- remove future error forwarding to cached request
- replace future forward test by checking that no http requests were made
- moved fragile tests to their owned class to prevent potential different results on different runs
- added Test constants
@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 341 Code Smells

80.4% 80.4% Coverage
4.0% 4.0% Duplication

@L-Applin L-Applin merged commit 556f341 into feature/master/imds Jan 10, 2023
@L-Applin L-Applin deleted the olapplin/imds-async-token branch January 10, 2023 18:12
aws-sdk-java-automation pushed a commit that referenced this pull request Feb 11, 2025
Minor fixes to address feedback and update changelog file
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.

2 participants