ASP.NET Web API OperationCanceledException when browser cancels the request

Question 1

This is a bug in ASP.NET Web API 2 and unfortunately, I don't think there's a workaround that will always succeed. We filed a bug to fix it on our side.

Ultimately, the problem is that we return a cancelled task to ASP.NET in this case, and ASP.NET treats a cancelled task like an unhandled exception (it logs the problem in the Application event log).

In the meantime, you could try something like the code below. It adds a top-level message handler that removes the content when the cancellation token fires. If the response has no content, the bug shouldn't be triggered. There's still a small possibility it could happen, because the client could disconnect right after the message handler checks the cancellation token but before the higher-level Web API code does the same check. But I think it will help in most cases.

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

Question 2

When implementing an exception logger for WebApi, it is recommend to extend the System.Web.Http.ExceptionHandling.ExceptionLogger class rather than creating an ExceptionFilter. The WebApi internals will not call the Log method of ExceptionLoggers for canceled requests (however, exception filters will get them). This is by design.

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

Question 3

Here's an other workaround for this issue. Just add a custom OWIN middleware at the beginning of the OWIN pipeline that catches the OperationCanceledException:

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

Question 4

I have found a bit more details on this error. There are 2 possible exceptions that can happen:

OperationCanceledException
TaskCanceledException

The first one happens if connection is dropped while your code in controller executes (or possibly some system code around that as well). While the second one happens if the connection is dropped while the execution is inside an attribute (e.g. AuthorizeAttribute).

So the provided workaround helps to mitigate partially the first exception, it does nothing to help with the second. In the latter case the TaskCanceledException occurs during base.SendAsync call itself rather that cancellation token being set to true.

I can see two ways of solving these:

Just ignoring both exceptions in global.asax. Then comes the question if it's possible to suddenly ignore something important instead?
Doing an additional try/catch in the handler (though it's not bulletproof + there is still possibility that TaskCanceledException that we ignore will be a one we want to log.

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

The only way I figured out we can try to pinpoint the wrong exceptions is by checking if stacktrace contains some Asp.Net stuff. Does not seem very robust though.

P.S. This is how I filter these errors out:

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

Question 5

You could try changing the default TPL task exception handling behavior through web.config:

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

Then have a static class (with a static constructor) in your web app, which would handle AppDomain.UnhandledException.

However, it appears that this exception is actually getting handled somewhere inside ASP.NET Web API runtime, before you even have a chance to handle it with your code.

In this case, you should be able to catch it as a 1st chance exception, with AppDomain.CurrentDomain.FirstChanceException, here is how. I understand this may not be what you are looking for.

Question 6

I sometimes get the same 2 exceptions in my Web API 2 application, however i can catch them with the Application_Error method in Global.asax.cs and using a generic exception filter.

The funny thing is, though, i prefer not to catch these exceptions, because i always log all the unhandled exceptions that can crash the application (these 2, however, are irrelevant for me and apparently don't or at least shouldn't crash it, but i may be wrong). I suspect these errors show up due to some timeout expiration or explicit cancellation from the client, but i would have expected them to be treated inside the ASP.NET framework and not propagated outside of it as unhandled exceptions.

Question 7

The OP mentioned the desire to ignore System.OperationCanceledException within ELMAH and even provides a link in the right direction. ELMAH has come a long way since the original post and it provides a rich capability to do exactly what the OP is requesting. Please see this page (still being completed) which outlines the programmatic and declarative (configuration-based) approaches.

My personal favorite is the declarative approach made directly in the Web.config. Follow the guide linked above to learn how to set up your Web.config for configuration-based ELMAH exception filtering. To specifically filter-out System.OperationCanceledException, you would use the is-type assertion as such:

<configuration>
  ...
  <elmah>
  ...
    <errorFilter>
      <test>
        <or>
          ...
          <is-type binding="BaseException" type="System.OperationCanceledException" />
          ...
        </or>
      </test>
    </errorFilter>
  </elmah>
  ...
</configuration>

Question 8

We have been receiving the same exception, we tried to use @dmatson's workaround, but we'd still get some exception through. We dealt with it until recently. We noticed some Windows logs growing at an alarming rate.

Error files located in: C:\Windows\System32\LogFiles\HTTPERR

Most of the errors's were all for "Timer_ConnectionIdle". I searched around and it seemed that even though the web api call was finished, the connection still persisted for two minutes past the original connection.

I then figured we should try to close the connection in the response and see what happens.

I added response.Headers.ConnectionClose = true; to the SendAsync MessageHandler and from what I can tell the clients are closing the connections and we aren't experiencing the issue any more.

I know this isn't the best solution, but it works in our case. I'm also i'm pretty sure performance-wise this isn't something you'd want to do if your API is getting multiple calls from the same client back-to-back.