ASP.NET Web API OperationCanceledException когда браузер отменяет запрос

при реализации регистратора исключений для WebApi рекомендуется расширить System.Web.Http.ExceptionHandling.ExceptionLogger класс, а не создание ExceptionFilter. Внутренние компоненты WebApi не будут вызывать метод журнала ExceptionLoggers для отмененных запросов (однако фильтры исключений получат их). Это сделано специально.

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>

есть static класса (с static конструктор) в вашем веб-приложении, которое будет обрабатывать AppDomain.UnhandledException.

однако, похоже, что это исключение на самом деле обрабатывается где-то внутри ASP.NET Web API runtime, прежде чем у вас даже есть шанс справиться с этим с помощью вашего кода.

в этом случае, вы должны быть возможность поймать его как исключение 1-го шанса, с AppDomain.CurrentDomain.FirstChanceException,вот как. Я понимаю, что это может быть не то, что вы ищете.

Я иногда получаю те же 2 исключения в моем приложении Web API 2, однако я могу поймать их с помощью Application_Error метод Global.asax.cs и, используя универсальный фильтр исключений.

самое смешное, однако, я предпочитаю не ловить эти исключения, потому что я всегда регистрирую все необработанные исключения, которые могут привести к сбою приложения (эти 2, однако, не имеют отношения ко мне и, по-видимому, не должны или, по крайней мере, не должны разбивать его, но я могу ошибаться). Я подозреваю эти ошибки появляется из-за истечения некоторого времени ожидания или явной отмены от клиента, но я ожидал бы, что они будут обработаны внутри ASP.NET фреймворк и не распространяется за его пределы как необработанные исключения.

я нашел немного больше информации об этой ошибке. Есть 2 возможных исключения, которые могут произойти:

1. OperationCanceledException
2. TaskCanceledException

первый происходит, если соединение отбрасывается во время выполнения вашего кода в контроллере (или, возможно, какой-то системный код вокруг этого). В то время как второй будет, если связь обрывается во время выполнения внутри атрибута (например,AuthorizeAttribute).

поэтому указанное решение помогает частично смягчить первое исключение, он ничего не делает, чтобы помочь со вторым. В последнем случае TaskCanceledException происходит во время base.SendAsync назовите себя скорее тем, что токен отмены установлен в true.

Я вижу два пути решения:

1. просто игнорируя оба исключения в глобальном.асакс. Тогда возникает вопрос, Можно ли внезапно игнорировать что-то важное вместо этого?
2. делаешь еще попробовать/ловить в обработчике (хотя это не пуленепробиваемый + есть еще возможность, что 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;
    }
}

единственный способ, которым я понял, что мы можем попытаться определить неправильные исключения, - это проверить, содержит ли stacktrace некоторые Asp.Net чепуха. Не кажется очень надежной.

P. S. Это, как мне фильтровать эти ошибки:

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". Я искал вокруг, и казалось, что, хотя вызов веб-api был завершен, соединение все еще сохранялось для через две минуты после первоначального соединения.

затем я решил, что мы должны попытаться закрыть соединение в ответе и посмотреть, что произойдет.

добавил response.Headers.ConnectionClose = true; в SendAsync MessageHandler и из того, что я могу сказать, клиенты закрывают соединения, и мы больше не испытываем проблемы.

Я знаю, что это не лучшее решение, но это работает в нашем случае. Я также уверен, что с точки зрения производительности это не то, что вы хотели бы сделать, если ваш API получает несколько вызовов от одного и того же клиента спина к спине.