'TaskCanceledException' shouldn't be thrown unless caller canceled the task!

In version 1.15.1

Oh the dreaded TaskCanceledException! What I have seen so many times now is that I am trying to run a bunch of functional tests in parallel. They all try to use the SDK in parallel, and then they all blow up like this:

var caches = await manager.Redis.ListByResourceGroupAsync(resourceGroup.Name); return caches.Where(c => c.ProvisioningState.Equals(“succeeded”, StringComparison.OrdinalIgnoreCase) && options.Matches(c, defaultRegion));

Message: System.Threading.Tasks.TaskCanceledException : A task was canceled.

Result StackTrace: at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Azure.Management.Redis.Fluent.RedisOperations.<ListByResourceGroupWithHttpMessagesAsync>d__11.MoveNext() — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Azure.Management.Redis.Fluent.RedisOperationsExtensions.<ListByResourceGroupAsync>d__6.MoveNext() — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() at ProvisioningTests.IRedisCachesExtensions.<GetAsync>d__0.MoveNext() in C:\repo\cp_psprod\test\FunctionalTests\ProvisioningTests\IRedisCachesExtensions.cs:line 17 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() at ProvisioningTests.Tests.TestBase.<GetOrCreateRedisCache>d__4.MoveNext() in C:\repo\cp_psprod\test\FunctionalTests\ProvisioningTests\Tests\TestBase.cs:line 40 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() at ProvisioningTests.Tests.ScaleUpDownTests.<ScaleUpDown>d__1.MoveNext() in C:\repo\cp_psprod\test\FunctionalTests\ProvisioningTests\Tests\ScaleUpDownTests.cs:line 21

[TimLovellSmith]

I think you are right that this is caused by the behavior of HttpClient. I would suggest you do one of two things:

1. Close as won’t fix, please get them to fix HttpClient instead, or:
2. Bake the workaround of checking for actual token cancellation into Fluent SDK, so that people can get a more natural experience like TimeoutException from Fluent SDK, and not have to face this confusing behavior of HttpClient. Despite this not always matching the behavior of HttpClient, at least it would allow you to design your own API’s behavior nicely, and follow the spirit of guidelines here

“Only the requesting object can issue the cancellation request, and each listener is responsible for noticing the request and responding to it in an appropriate and timely manner.”

“Requesting is distinct from listening. An object that invokes a cancelable operation can control when (if ever) cancellation is requested.”

https://docs.microsoft.com/en-us/dotnet/standard/threading/cancellation-in-managed-threads?redirectedfrom=MSDN

=> (bottom line, if I didn’t cancel the task, it shouldn’t be canceled!)

(Community, if you agree TimeoutException is better please upvote issue, if you think TaskCanceledExceptions are great and should be expected all the time even when you didn’t request them, please downvote…)

[xseeseesee]

@TimLovellSmith @qub1n Here are two options for you to set in your code and test if you still face the same issue.

• Add retry policy

var azure = Microsoft.Azure.Management.Fluent.Azure.Configure()
                        .WithLogLevel(HttpLoggingDelegatingHandler.Level.BodyAndHeaders)
                        .WithRetryPolicy(new RetryPolicy(new HttpStatusCodeErrorDetectionStrategy(), 3))
                        .Authenticate(azureCredentials)
                        .WithDefaultSubscription();

Please check details here for using RetryPolicy

• Increase http client timeout

var rm = azure.ManagementClients
            .Where(c => c is IResourceManagementClient)
            .DefaultIfEmpty(null)
            .FirstOrDefault() as IResourceManagementClient;
(rm as IAzureClient).HttpClient.Timeout = TimeSpan.FromMinutes(5);

Please feel free to let me know if these help.