ブラウザーがリクエストをキャンセルしたときのASP.NET Web API OperationCanceledException

ユーザーがページを読み込むと、ASP.NET Web API 2コントローラーにヒットする1つまたは複数のajax要求が行われます。ユーザーが別のページに移動した場合、これらのajaxリクエストが完了する前に、リクエストはブラウザーによってキャンセルされます。次に、ELMAH HttpModuleは、キャンセルされたリクエストごとに2つのエラーをログに記録します。

エラー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()

エラー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)

スタックトレースを見ると、ここから例外がスローされていることがわかります：https : //github.com/ASP-NET-MVC/aspnetwebstack/blob/master/src/System.Web.Http.WebHost/HttpControllerHandler.cs# L413

私の質問は次のとおりです。これらの例外をどのように処理して無視できますか？

ユーザーコードの外にあるようです...

ノート：

• ASP.NET Web API 2を使用しています
• Web APIエンドポイントは、非同期メソッドと非非同期メソッドの混合です。
• エラーログをどこに追加しても、ユーザーコードで例外をキャッチできません
  • Global.asax Applicaiton_Error
  • TaskScheduler.UnobservedTaskException
  • ELMAHエラーフィルタリングvoid ErrorLog_Filtering（https://code.google.com/p/elmah/wiki/ErrorFiltering）

これはASP.NET Web API 2のバグであり、残念ながら、常に成功する回避策はないと思います。私たちはそれを私たちの側で修正するためにバグを提出しました。

最終的に問題は、この場合、キャンセルされたタスクをASP.NETに返すことであり、ASP.NETはキャンセルされたタスクを未処理の例外のように扱います（アプリケーションイベントログに問題を記録します）。

それまでの間、以下のコードのようなものを試すことができます。キャンセルトークンが発生したときにコンテンツを削除するトップレベルのメッセージハンドラーを追加します。応答にコンテンツがない場合、バグは発生しません。メッセージハンドラーがキャンセルトークンをチェックした直後に、より高いレベルのWeb APIコードが同じチェックを行う前に、クライアントが切断される可能性があるため、発生する可能性はまだわずかです。しかし、それはほとんどの場合に役立つと思います。

デビッド

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;
    }
}

WebApiの例外ロガーを実装する場合System.Web.Http.ExceptionHandling.ExceptionLogger、ExceptionFilterを作成するのではなく、クラスを拡張することをお勧めします。WebApi内部は、キャンセルされたリクエストに対してExceptionLoggersのLogメソッドを呼び出しません（ただし、例外フィルターはそれらを取得します）。これは仕様によるものです。

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

この問題の別の回避策を次に示します。をキャッチするOWINパイプラインの先頭にカスタムOWINミドルウェアを追加するだけですOperationCanceledException。

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

次の方法で、デフォルトのTPLタスクの例外処理動作を変更してみてくださいweb.config。

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

次に、Webアプリにstaticクラス（staticコンストラクター付き）を用意します。AppDomain.UnhandledException。

ただし、この例外は実際には、コードで処理する前にASP.NET Web APIランタイム内のどこかで処理されているようです。

この場合は、あなたがして、第一のチャンス例外として、それをキャッチすることができるはずAppDomain.CurrentDomain.FirstChanceException、ここにどのようにあります。これはあなたが探しているものではない可能性があることを理解しています。

Web API 2アプリケーションで同じ2つの例外が発生することがありますが、Application_ErrorメソッドGlobal.asax.csの汎用例外フィルターを使用してそれらをキャッチできます。

ただし、面白いのは、これらの例外をキャッチしないことです。これは、アプリケーションをクラッシュさせる可能性があるすべての未処理の例外を常にログに記録するためです（ただし、これら2つは私には無関係で、クラッシュしないか、少なくともクラッシュしないはずです）。それ、しかし私は間違っているかもしれません）。タイムアウトの期限切れやクライアントからの明示的なキャンセルが原因でこれらのエラーが表示されると思いますが、ASP.NETフレームワーク内で処理され、その外に未処理の例外として伝播されないことが期待されました。

このエラーについてもう少し詳しく知りました。発生する可能性のある2つの可能な例外があります。

1. OperationCanceledException
2. TaskCanceledException

最初の問題は、コントローラー内のコードの実行中に接続が切断された場合に発生します（またはその周りのシステムコードも同様です）。2番目は、実行が属性内にあるときに接続がドロップされた場合に発生します（たとえば、AuthorizeAttribute。

したがって、提供された回避策は、最初の例外を部分的に軽減するのに役立ちますが、2番目の例外には役立ちません。後者の場合、キャンセルトークンがtrueに設定されるのではなく、呼び出し自体のTaskCanceledException間に発生base.SendAsyncします。

これらを解決する方法は2つあります。

1. global.asaxで両方の例外を無視するだけです。次に、代わりに重要な何かを突然無視することが可能かどうかという質問が来ますか？
2. ハンドラーで追加のtry / catchを実行します（これは完全なものではありませんTaskCanceledExceptionが、ログに記録したいものは無視される可能性があります。

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;
    }
}

誤った例外を特定しようとする唯一の方法は、スタックトレースにAsp.Netの要素が含まれているかどうかを確認することです。とはいえ、あまり堅牢ではないようです。

PSこれは私がこれらのエラーを取り除く方法です：

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

同じ例外が発生しました。@ dmatsonの回避策を使用しようとしましたが、それでも例外が発生します。最近まで対応してきました。一部のWindowsログが驚くべき速度で増加していることに気付きました。

C：\ Windows \ System32 \ LogFiles \ HTTPERRにあるエラーファイル

エラーのほとんどはすべて「Timer_ConnectionIdle」に関するものでした。周りを検索したところ、Web API呼び出しが終了したにもかかわらず、接続は元の接続を2分間超えたままでした。

次に、応答で接続を閉じて、何が起こるかを確認する必要があると考えました。

追加した response.Headers.ConnectionClose = true;SendAsync MessageHandlerしましたが、クライアントから接続が閉じられていることがわかり、問題はもう発生していません。

これが最善の解決策ではないことはわかっていますが、私たちの場合はうまくいきます。また、パフォーマンスに関しては、APIが同じクライアントから連続して複数の呼び出しを取得している場合、これは実行したくないものだと私は確信しています。