Avoid corrupting internal maps when disco.Disco and auth.CachingCredentialsSource get concurrent calls #35
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.
Both
disco.Disco
andauth.CachingCredentialsSource
internally use maps to represent caches of earlier results, but previously neither of them was making any effort to be concurrency-safe in updating those maps, which meant that concurrent calls could potentially corrupt those maps, or panic as seen in hashicorp/terraform#33333.To avoid pushing synchronization complexity down into callers, we'll guard all accesses of these maps using a
sync.Mutex
. These mutexes are used only to ensure integrity of the maps themselves, and intentionally do not prevent concurrent calls to the real operations whose results are being cached. This means that it's possible in principle for two goroutines to race to populate the cache and it's unspecified which one will "win", but regardless of which one wins the maps should still be left in a consistent state for future reads and we should avoid any more concurrent access panics.