Distinguir el tiempo de espera de la cancelación del usuario

Question

HttpClient tiene una función de tiempo de espera interno (a pesar de ser todo asíncrono, es decir, los tiempos de espera pueden considerarse ortogonales a la funcionalidad de solicitud http y por lo tanto ser manejado por utilidades asíncronas genéricas, pero aparte) y cuando expira el tiempo de espera , lanzará un TaskCanceledException (envuelto en un AggregateException).

El TCE contiene un CancellationToken que equivale a CancellationToken.None.

Ahora bien, si proporciono HttpClient con un CancellationToken de mi propia y usarlo para cancelar la operación antes de que termine (o el tiempo de espera), tengo la misma exacta TaskCanceledException, de nuevo con un CancellationToken.None.

¿Existe todavía una forma, mirando solamente la excepción lanzada, para averiguar si un tiempo de espera de la solicitud cancelada, sin tener que hacer mi propia CancellationToken accesible para el código que comprueba la excepción?

P.S. ¿Podría ser un error y CancellationToken se corrigió de alguna manera erróneamente en CancellationToken.None? En el cancelado utilizando el caso Custom CancellationToken, esperaría que TaskCanceledException.CancellationToken iguale ese token personalizado.

Editar Para hacer que el problema un poco más clara, con acceso a la original CancellationTokenSource, es fácil de distinguir de tiempo de espera y el usuario cancelación:

== origCancellationTokenSource.IsCancellationRequested cierto

Obteniendo el CancellationToken de la excepción, da la respuesta incorrecta:

((TaskCanceledException) e.InnerException) .CancellationToken.IsCancellationRequested == falsa

Aquí un ejemplo mínimo, debido a la demanda popular:

public void foo() 
{ 
    makeRequest().ContinueWith(task => 
    { 
     try 
     { 
      var result = task.Result; 
      // do something with the result; 
     } 
     catch (Exception e) 
     { 
      TaskCanceledException innerException = e.InnerException as TaskCanceledException; 
      bool timedOut = innerException != null && innerException.CancellationToken.IsCancellationRequested == false; 

      // Unfortunately, the above .IsCancellationRequested 
      // is always false, no matter if the request was 
      // cancelled using CancellationTaskSource.Cancel() 
      // or if it timed out 
     } 
    }); 
} 

public Task<HttpResponseMessage> makeRequest() 
{ 
    var cts = new CancellationTokenSource(); 
    HttpClient client = new HttpClient() { Timeout = TimeSpan.FromSeconds(10) }; 
    HttpRequestMessage httpRequestMessage = new HttpRequestMessage(HttpMethod.Get, "url"); 

    passCancellationTokenToOtherPartOfTheCode(cts); 
    return client.SendAsync(httpRequestMessage, cts.Token); 
} 

Answer 1

Sí, ambos devuelven la misma excepción (posiblemente debido al tiempo de espera internamente usando un token también) pero se puede resolver fácilmente haciendo esto:

catch (OperationCanceledException ex) 
      { 
       if (token.IsCancellationRequested) 
       { 
        return -1; 
       } 

       return -2; 
      } 

así que básicamente si se golpea la excepción, sino que su ficha no es cancelado, así que fue un tiempo de espera de HTTP normal

Answer 2

La respuesta aceptada es ciertamente cómo este debe trabajo en la teoría, pero, por desgracia, en la práctica IsCancellationRequested hace no (fiable) consiga el sistema en la ficha que se adjunta a la excepción:

Cancelling an HttpClient Request - Why is TaskCanceledException.CancellationToken.IsCancellationRequested false?