-
Notifications
You must be signed in to change notification settings - Fork 24
Description
I'm having issues when using InstancePrincipalsAuthenticationDetailsProvider. My application hangs as soon as the authentication process begins. After checking the source code, I noticed multiple usages of .Result.
In my case, the deadlock occurs in the .Result in
AbstractRequestingAuthenticationDetailsProvider -> AutoDetectEndpointUsingMetadataUrl().
Using .Result should be avoided because, depending on the synchronization context, it can lead to deadlocks (in my case, ASP.NET 4.8, but other contexts may be affected as well).
The ideal approach is to make the code fully asynchronous. However, if a synchronous call is really necessary, it should use .ConfigureAwait(false).GetAwaiter().GetResult() instead of .Result, to allow the continuation to run on a different thread and prevent deadlocks.
Steps to Reproduce
Create an ASP.NET 4.8 application (or any environment with a synchronization context).
Use any function with InstancePrincipalsAuthenticationDetailsProvider for authentication (in my case, I was using KmsCryptoClient) inside a route in a controller.
Ex.:
using (var client = new KmsCryptoClient(authProvider, new ClientConfiguration(), cryptoEndpoint))
{
var response = await client.Encrypt(encryptRequest, cancellationToken: cancellationToken).ConfigureAwait(false);
return new EncryptedData { Value = response.EncryptedData.Ciphertext, KeyVersion = response.EncryptedData.KeyVersionId };
}
Result:
The process will hang at client.Encrypt
Temporary Workaround
As a temporary workaround, the issue can be avoided by running the async call in a separate thread pool context, using Task.Run(...):
var result = Task.Run(() => provider.GetAuthTokenAsync()).Result;
This prevents the deadlock because it executes the async method outside the synchronization context.
However, this is only a temporary workaround — it introduces additional thread pool overhead and should be replaced by a proper async implementation in the library.