Fix blocking sleep and incorrect backoff durations in RefreshNowAsync (#196)
Description
Why is this change being made?
RefreshNowAsyncusesThread.Sleepwhich blocks a thread pool thread, causing thread pool starvation and ignoring theCancellationToken.exceptionCountis never incremented, so exponential backoff never grows — every retry uses the same base delay..Milliseconds(sub-second component only, 0–999) is used instead of the fullTimeSpan, truncating intended ~7s delays to ~400ms.Environment.TickCount(32-bit signed int) overflows after ~24.9 days, causing incorrect retry timing in long-running services.What is changing?
- Replace
Thread.Sleepwithawait Task.Delay(TimeSpan, CancellationToken)so the wait is non-blocking and cancellable.- Increment
exceptionCountin the catch block so backoff actually grows exponentially.- Use
TimeSpandirectly instead of extracting.Milliseconds, fixing the truncated delay durations.- Replace
Environment.TickCountarithmetic withDateTime.UtcNow+TimeSpanfor overflow-safe timing.Related Links
- Issue #, if available: N/A
Testing
How was this tested?
- Added
RefreshNowAsyncRespectsTokenCancellation— verifies cancellation is immediate (<100ms) during the jitter delay.- Added
RefreshNowAsyncAfterExceptionWithExpiredBackoff— covers the branch wherenextRetryTimeis in the past (wait is negative), confirming recovery works.- Added
RefreshNowAsyncAfterExceptionWithActiveBackoff— covers the branch where backoff wait exceeds base jitter, verified via cancellation.- All 17 existing tests pass.
When testing locally, provide testing artifact(s):
dotnet test— all tests pass including the 3 new ones.
Reviewee Checklist
Update the checklist after submitting the PR
- I have reviewed, tested and understand all changes If not, why:
- I have filled out the Description and Testing sections above If not, why:
- Build and Unit tests are passing If not, why:
- Unit test coverage check is passing If not, why:
- Integration tests pass locally If not, why: No integration test suite in this repository.
- I have updated integration tests (if needed)
If not, why: Not applicable — changes are to caching internals, no integration tests exist.
- I have ensured no sensitive information is leaking (i.e., no logging of sensitive fields, or otherwise) If not, why:
- I have added explanatory comments for complex logic, new classes/methods and new tests If not, why:
- I have updated README/documentation (if needed)
If not, why: No public API changes; behavioral change (longer jitter delay) is noted in the PR description.
- I have clearly called out breaking changes (if any)
If not, why: Behavioral change:
RefreshNowAsyncnow waits the originally intended ~7s jitter (was ~400ms due to the.Millisecondsbug). This is a correction, not a regression.
Reviewer Checklist
All reviewers please ensure the following are true before reviewing:
- Reviewee checklist has been accurately filled out
- Code changes align with stated purpose in description
- Test coverage adequately validates the changes
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Co-authored-by: Simon Marty simon.marty0@gmail.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
AWS Secrets Manager Caching Client for .NET
The AWS Secrets Manager caching client enables in-process caching of secrets for .NET applications.
Required Prerequisites
To use this client, you must have:
A .NET project with one of the following:
An Amazon Web Services (AWS) account to access secrets stored in AWS Secrets Manager and use AWS SDK for .NET.
To create an AWS account, go to Sign In or Create an AWS Account and then choose I am a new user. Follow the instructions to create an AWS account.
To create a secret in AWS Secrets Manager, go to Creating Secrets and follow the instructions on that page.
To download and install the AWS SDK for .NET, go to Installing the AWS SDK for .NET in the AWS SDK for .NET documentation and then follow the instructions on that page.
Download
You can get the latest release from
Nuget:Getting Started
The following code sample demonstrates how to start using the caching client:
GetSecretStringorGetSecretBinary.Cache Configuration
You can configure the
SecretCacheConfigurationobject with the following parameters:CacheItemTTL- The TTL of a Cache item in milliseconds. The default value is3600000ms, or 1 hour.MaxCacheSize- The maximum number of items the Cache can contain before evicting using LRU. The default value is1024.VersionStage- The Version Stage the Cache will request when retrieving secrets from Secrets Manager. The default value isAWSCURRENT.Client- The Secrets Manager client to be used by the Cache. The default value isnull, which causes the Cache to instantiate a new Secrets Manager client.CacheHook- An implementation of the ISecretCacheHook interface. The default value isnull.Post-Quantum TLS Support
This library automatically supports Post-Quantum TLS when available on the underlying platform:
export DOTNET_SYSTEM_NET_SECURITY_USENETWORKFRAMEWORK=1Getting Help
We use GitHub issues for tracking bugs and caching library feature requests and have limited bandwidth to address them. Please use these community resources for getting help:
License
This library is licensed under the Apache 2.0 License.