API Web ASP.NET OperationCanceledException quando il browser annulla la richiesta

Quando un utente carica una pagina, effettua una o più richieste ajax, che colpiscono i controller ASP.NET Web API 2. Se l'utente naviga in un'altra pagina, prima che queste richieste ajax vengano completate, le richieste vengono annullate dal browser. Il nostro ELMAH HttpModule registra quindi due errori per ogni richiesta annullata:

Errore 1:

System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.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.TaskAwaiter`1.GetResult()
   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.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.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__2.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.TaskAwaiter`1.GetResult()
   at System.Web.Http.Controllers.ExceptionFilterResult.<ExecuteAsync>d__0.MoveNext()

Errore 2:

System.OperationCanceledException: The operation was canceled.
   at System.Threading.CancellationToken.ThrowIfCancellationRequested()
   at System.Web.Http.WebHost.HttpControllerHandler.<WriteBufferedResponseContentAsync>d__1b.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.Web.Http.WebHost.HttpControllerHandler.<CopyResponseAsync>d__7.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.Web.Http.WebHost.HttpControllerHandler.<ProcessRequestAsyncCore>d__0.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.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Guardando lo stacktrace, vedo che l'eccezione viene generata da qui: https://github.com/ASP-NET-MVC/aspnetwebstack/blob/master/src/System.Web.Http.WebHost/HttpControllerHandler.cs# L413

La mia domanda è: come posso gestire e ignorare queste eccezioni?

Sembra essere al di fuori del codice utente ...

Appunti:

• Sto usando ASP.NET Web API 2
• Gli endpoint dell'API Web sono una combinazione di metodi asincroni e non asincroni.
• Non importa dove aggiungo la registrazione degli errori, non sono in grado di rilevare l'eccezione nel codice utente
  • global.asax Applicaiton_Error
  • TaskScheduler.UnobservedTaskException
  • Filtro errori ELMAH void ErrorLog_Filtering( https://code.google.com/p/elmah/wiki/ErrorFiltering )

Questo è un bug nell'API Web ASP.NET 2 e, sfortunatamente, non credo che ci sia una soluzione alternativa che avrà sempre successo. Abbiamo presentato un bug per risolverlo dalla nostra parte.

In definitiva, il problema è che in questo caso restituiamo un'attività annullata ad ASP.NET e ASP.NET tratta un'attività annullata come un'eccezione non gestita (registra il problema nel registro eventi dell'applicazione).

Nel frattempo, potresti provare qualcosa di simile al codice qui sotto. Aggiunge un gestore di messaggi di primo livello che rimuove il contenuto quando viene attivato il token di annullamento. Se la risposta non ha contenuto, il bug non dovrebbe essere attivato. C'è ancora una piccola possibilità che possa accadere, perché il client potrebbe disconnettersi subito dopo che il gestore dei messaggi ha verificato il token di annullamento ma prima che il codice API Web di livello superiore esegua lo stesso controllo. Ma penso che aiuterà nella maggior parte dei casi.

David

config.MessageHandlers.Add(new CancelledTaskBugWorkaroundMessageHandler());

class CancelledTaskBugWorkaroundMessageHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        HttpResponseMessage response = await base.SendAsync(request, cancellationToken);

        // Try to suppress response content when the cancellation token has fired; ASP.NET will log to the Application event log if there's content in this case.
        if (cancellationToken.IsCancellationRequested)
        {
            return new HttpResponseMessage(HttpStatusCode.InternalServerError);
        }

        return response;
    }
}

Quando si implementa un logger di eccezioni per WebApi, si consiglia di estendere la System.Web.Http.ExceptionHandling.ExceptionLoggerclasse invece di creare un ExceptionFilter. Gli interni di WebApi non chiameranno il metodo Log di ExceptionLoggers per le richieste annullate (tuttavia, i filtri di eccezione le otterranno). Questo è di progettazione.

HttpConfiguration.Services.Add(typeof(IExceptionLogger), myWebApiExceptionLogger); 

Ecco un'altra soluzione alternativa per questo problema. Basta aggiungere un middleware OWIN personalizzato all'inizio della pipeline OWIN che cattura OperationCanceledException:

#if !DEBUG
app.Use(async (ctx, next) =>
{
    try
    {
        await next();
    }
    catch (OperationCanceledException)
    {
    }
});
#endif

È possibile provare a modificare il comportamento di gestione delle eccezioni dell'attività TPL predefinito tramite web.config:

<configuration> 
    <runtime> 
        <ThrowUnobservedTaskExceptions enabled="true"/> 
    </runtime> 
</configuration>

Quindi avere una staticclasse (con un staticcostruttore) nella tua app web, che gestirà AppDomain.UnhandledException.

Tuttavia, sembra che questa eccezione venga effettivamente gestita da qualche parte all'interno del runtime dell'API Web ASP.NET , prima ancora che tu abbia la possibilità di gestirla con il tuo codice.

In questo caso, dovresti essere in grado di catturarlo come prima eccezione di possibilità, con AppDomain.CurrentDomain.FirstChanceException, ecco come . Capisco che questo potrebbe non essere quello che stai cercando.

A volte ottengo le stesse 2 eccezioni nella mia applicazione Web API 2, tuttavia posso rilevarle con il Application_Errormetodo Global.asax.cse utilizzando un filtro di eccezione generico .

La cosa divertente è, però, che preferisco non rilevare queste eccezioni, perché registro sempre tutte le eccezioni non gestite che possono mandare in crash l'applicazione (queste 2, tuttavia, sono irrilevanti per me e apparentemente non lo fanno o almeno non dovrebbero andare in crash ma potrei sbagliarmi). Sospetto che questi errori si presentino a causa di una scadenza di timeout o di una cancellazione esplicita da parte del client, ma mi sarei aspettato che fossero trattati all'interno del framework ASP.NET e non propagati al di fuori di esso come eccezioni non gestite.

Ho trovato qualche dettaglio in più su questo errore. Ci sono 2 possibili eccezioni che possono verificarsi:

1. OperationCanceledException
2. TaskCanceledException

Il primo si verifica se la connessione viene interrotta durante l'esecuzione del codice nel controller (o forse anche del codice di sistema attorno a quello). Mentre il secondo accade se la connessione viene interrotta mentre l'esecuzione è all'interno di un attributo (es AuthorizeAttribute.).

Quindi la soluzione alternativa fornita aiuta a mitigare parzialmente la prima eccezione, non fa nulla per aiutare con la seconda. In quest'ultimo caso si TaskCanceledExceptionverifica durante la base.SendAsyncchiamata stessa piuttosto che il token di cancellazione viene impostato su true.

Posso vedere due modi per risolverli:

1. Ignorando entrambe le eccezioni in global.asax. Poi viene la domanda se è possibile ignorare improvvisamente qualcosa di importante invece?
2. Facendo un ulteriore tentativo / cattura nel gestore (sebbene non sia a prova di proiettile + c'è ancora la possibilità che TaskCanceledExceptionquello che ignoriamo sia quello che vogliamo registrare.

config.MessageHandlers.Add(new CancelledTaskBugWorkaroundMessageHandler());

class CancelledTaskBugWorkaroundMessageHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        try
        {
            HttpResponseMessage response = await base.SendAsync(request, cancellationToken);

            // Try to suppress response content when the cancellation token has fired; ASP.NET will log to the Application event log if there's content in this case.
            if (cancellationToken.IsCancellationRequested)
            {
                return new HttpResponseMessage(HttpStatusCode.InternalServerError);
            }
        }
        catch (TaskCancellationException)
        {
            // Ignore
        }

        return response;
    }
}

L'unico modo in cui ho capito che possiamo provare a individuare le eccezioni sbagliate è controllare se stacktrace contiene alcune cose Asp.Net. Non sembra però molto robusto.

PS Ecco come filtrare questi errori:

private static bool IsAspNetBugException(Exception exception)
{
    return
        (exception is TaskCanceledException || exception is OperationCanceledException) 
        &&
        exception.StackTrace.Contains("System.Web.HttpApplication.ExecuteStep");
}

Abbiamo ricevuto la stessa eccezione, abbiamo provato a utilizzare la soluzione alternativa di @ dmatson, ma avremmo comunque ottenuto qualche eccezione. Ne abbiamo parlato fino a poco tempo fa. Abbiamo notato che alcuni registri di Windows crescono a una velocità allarmante.

File di errore situati in: C: \ Windows \ System32 \ LogFiles \ HTTPERR

La maggior parte degli errori erano tutti per "Timer_ConnectionIdle". Ho cercato in giro e sembrava che anche se la chiamata web api fosse terminata, la connessione persisteva ancora per due minuti dopo la connessione originale.

Quindi ho pensato che dovremmo provare a chiudere la connessione nella risposta e vedere cosa succede.

Ho aggiunto response.Headers.ConnectionClose = true; a SendAsync MessageHandler e da quello che posso dire i client stanno chiudendo le connessioni e non stiamo più riscontrando il problema.

So che questa non è la soluzione migliore, ma nel nostro caso funziona. Sono anche abbastanza sicuro che dal punto di vista delle prestazioni questo non è qualcosa che vorresti fare se la tua API riceve più chiamate dallo stesso client back-to-back.