Cancellationtoken not Triggering when using IIS

[pawod]

I'm working on a ASP.NET Core web application running on regular net461 (also tried net48), where I defined an HTTP endpoint like this:

[HttpGet]
[Route("query/{queryName}")]
public async Task<IActionResult> Call(string queryName, CancellationToken cancellationToken)
{
  await Task.Delay(5_000, cancellationToken);
  ...
}

As the title already states, I can't make the cancellationToken trigger a TaskCanceledException upon initiating a refresh on browser side, while the initial request is still being processed (Chrome devtools displays these events as cancelled requests). The only way I can make it work, is by selecting "Project" in Visual Studio's Debug settings (see here), which I guess, makes the whole application run in Kestrel only - without any reverse proxy in front.

I came across various posts on SO (like this one) and GitHub (like this one) that claimed this issue would be solved with ASP.NET Core 2.2, where in-process hosting should work in combination with CancellationToken.

So I updated all my nuget packages, but unfortunately with no effect, the error still persists. Yes, locally I'm debugging using IIS Express and I'm not sure how exactly this differs from a regular IIS setup, but I'm also running this app on Azure, where the whole process looks like it was running in-process, because there is only a single process running (see here).

This is an extract from my csproj with the AspNetCore packages I installed:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.13.1" />
    <PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Server.IIS" Version="2.2.6" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.2.0" />
    <PackageReference Include="System.Net.Http" Version="4.3.4" />
  </ItemGroup>
</Project>

I also played around with the Program.cs, because I suspect this might be another potential source of error. I Tried to use the UseIIS() extension method only to enforce in-process hosting, but also no visible effect with regard to CancellationToken:

public class Program
{
    public static void Main(string[] args)
    {
        var host = WebHost.CreateDefaultBuilder(args)
            //.UseKestrel()
            .UseIIS()
            .UseContentRoot(Directory.GetCurrentDirectory())
            //.UseIISIntegration()
            .UseStartup<Startup>()
            .UseApplicationInsights()
            .Build();

        host.Run();
    }
}

What am I doing wrong? Does CancellationToken only work with netcoreapp2.x (or higher) as target framework? Might this be a configuration issue (Program.cs, Startup.cs, csproj, etc)?

[analogrelay]

@pawod FYI .NET Core 2.2 is end-of-life and no longer supported. We recommend upgrading to 3.1, which is a long-term servicing release. Or if you are still on .NET Framework, you should remain on 2.1 (the previous long-term servicing release). See the full .NET Core support policy for details.

Having said that, we can try to help investigate further and find out what's wrong, we just can't commit to supporting an end-of-life release. I'll see if @jkotalik or @Tratcher have any initial thoughts.

[pawod]

@anurse thanks for the response, I just tried the 2.1 packages with no success. On SO I got following comment regarding this issue (link)

Bottom line is you can't depend on CancellationToken being triggered. As far as details go, IIRC .NET Framework had a nasty race condition that could cause a crash, so they turned off support for CT-reported loss of connections. I believe that has been fixed in .NET Core.

Can you or anyone else confirm this? I guess I will need to migrate the entire project to netcoreapp3.1 in order to be able to use the latest ASP.NET Core packages.

EDIT: I've just ran some local tests with a fresh ASP.NET Core Web API project targeting netcoreapp3.1 and the basic issue still persists. When running my app on anything else, than Kestrel only, the CancellationToken is not triggered. By "Kestrel only" I refer to the same debug settings as described above. Using these settings, the server logs are visible on that external black command line window and the system tray does not show the small IIS Express icon.

Is it possible that CancellationTokens only trigger, when the app is hosted on a standalone Kestrel server without any reverse proxy?

[analogrelay]

On SO I got following comment regarding this issue (link)

I can't speak to that, but it could be possible.

I've just ran some local tests with a fresh ASP.NET Core Web API project targeting netcoreapp3.1 and the basic issue still persists.

Can you share your sample application and exactly how you tested it so we can try to reproduce this?

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[pawod]

Sorry for the late answer, but we had an Azure support request started in the meantime to exclude that this is an actual issue with the framework. After 5 weeks the support finally figured out that they're using a layer seven load balancer, which does not forward connection-close events to the App Service.

Here is their original answer:

RCA attached below:

The Microsoft Azure Team has investigated the issue you reported on configuring App Service to run without IIS reverse-proxy. In App Service, HTTP requests will first reach front end before sent to the worker which runs your application. The front end is a layer seven-load balancer, acting as a proxy, distributing incoming HTTP requests between different applications and their respective Workers. Between front end and worker, we implement connection pooling & reuse to avoid TCP setup-and-teardown overhead on every request. When frontend receives disconnect notion from the client side, the notion will not flow to the worker since we are reusing connections. In fact, proxies are very usual in the cloud world, and it is the same case for App Service. It is by design that IIS reverse-proxy is an integral part in App Service architecture. It is also expected that CancellationToken feature is not applicable to App Service.

To fundamentally solve the issue in the cloud world, please look into using other reverse-proxy-friendly mechanism, for example WebSockets or SignalR to achieve the same purpose . It’s also recommended to implement the request cancelling mechanism from server side to guard server against long running operations.

We are continuously taking steps to improve the Azure Web App service and we apologize for any inconvenience.

Regards,
The Microsoft Azure Team

Long story short: It is an issue caused by Azure's infrastructure and not the framework itself.