Fix concurrent cache access in AcquireToken method#578
Conversation
|
| httpClient: shared.DefaultClient, | ||
| retryPolicyEnabled: true, | ||
| source: source, | ||
| canRefresh: &zero, |
There was a problem hiding this comment.
Also remove the declaration of zero
| for err := range errors { | ||
| t.Error(err) | ||
| } |
There was a problem hiding this comment.
Consider this approach instead. If there were 100 identical errors, would you want to see all of them in go test output?
|
|
||
| // Mock client should only need to respond once if caching works correctly | ||
| mockClient := mock.NewClient() | ||
| // Add multiple responses in case caching fails (but we'll verify it doesn't) |
There was a problem hiding this comment.
if you simply appended 1 response the mock would panic when it gets a second request and you wouldn't have to count the requests yourself
| return | ||
| } | ||
|
|
||
| // Capture the token received |
There was a problem hiding this comment.
why? There can only be one token because the mock client returns a static value, and you don't need this to know whether the goroutine succeeded because if it didn't it would have written an error to the channel
3 participants
PR: Fix Concurrent Cache Access in
AcquireTokenMethodSummary
This PR addresses a potential race condition in the
AcquireTokenmethod by properly synchronizing access to the cache using a mutex. Issue number #569Changes
cacheAccessorMu.Lock()/defer cacheAccessorMu.Unlock()around cache operations to ensure thread-safe access.canRefreshatomic variable, which was previously used to prevent concurrent refreshes which is no longer needed as whole cache is in mutexTesting
TestAcquireTokenConcurrencyunit test to ensure correct behavior under concurrent conditions.Breaking Changes