Reduce redundant logging during ChainedTokenCredential.get_token() #19283
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.
This PR closes #18972 by reducing redundant logging during
ChainedTokenCredential.get_token()
and, by inheritance,DefaultAzureCredential.get_token()
. The rationale is that whenget_token()
fails for a credential chain, it logs an aggregate of the inner credentials' error messages, making those credentials' logging of same redundant. Similarly, whenget_token()
succeeds, users will seldom find error messages from unavailable inner credentials interesting. On the contrary, those messages can be confusing: "Why do I see half a dozen error messages when authentication succeeds?"Here's the diff for DefaultAzureCredential failure given typical logging configuration (filtering
DEBUG
messages):Similarly, DefaultAzureCredential success:
Inner credentials still log these messages, however they do so at
DEBUG
level when they're invoked by ChainedTokenCredential, using a ContextVar to determine whether that's the case. Unfortunately, ContextVar was added in Python 3.7. For Python 3.6, we have a backport. The nearest equivalent available to 2.7 isthreading.local
, which isn't concurrency-safe. Another alternative that works everywhere is to pass around an internal keyword argument, but 🤮In the end, because this isn't a functional or API change, I don't mind excluding 2.7. Similarly, if the backport is unacceptable, I observe that 3.6 will be EOL in 6 months. But that's just my opinion, please feel free to change my mind or propose alternative solutions 😄