Async handlers and cancellation

Kestrel runs request code on thread pool threads. An await on I/O returns the thread to the pool until the I/O completes, so a few threads can serve thousands of concurrent requests. Blocking on a task with .Result, .Wait() or GetAwaiter().GetResult() keeps the thread occupied while doing nothing. Under load the pool runs out of free threads and grows slowly, and latency climbs for every request: thread pool starvation. ASP.NET Core has no SynchronizationContext, so the classic UI-app deadlock does not happen; starvation is the failure mode.

The request's token

HttpContext.RequestAborted is a CancellationToken that is cancelled when the client disconnects. A handler parameter of type CancellationToken is bound to it, in minimal APIs and controllers alike:

app.MapGet("/reports/{id}", async (int id, ShopDb db, CancellationToken ct) =>
    await db.Reports.Where(r => r.Id == id).ToListAsync(ct));

Cancellation is cooperative. The token is only a flag; nothing stops your code unless it checks the flag (ThrowIfCancellationRequested) or passes the token to an API that does, such as EF Core's ...Async(ct) methods, HttpClient and Task.Delay. Cancellation surfaces as an OperationCanceledException (or its subclass TaskCanceledException).

1public static class Solution2{3    // The sandbox calls a synchronous entry point; a real handler would simply be async.4    public static List<string> Run() => RunAsync().GetAwaiter().GetResult();5 6    static async Task<List<string>> RunAsync()7    {8        var log = new List<string>();9        using var cts = new CancellationTokenSource();10        try11        {12            for (int item = 1; item <= 5; item++)13            {14                cts.Token.ThrowIfCancellationRequested();15                log.Add("processed " + item);16                if (item == 3)17                {18                    cts.Cancel();                       // the client disconnects here19                    log.Add("cancelled, still running item " + item);20                }21            }22        }23        catch (OperationCanceledException e)24        {25            log.Add("stopped by " + e.GetType().Name);26        }27 28        try29        {30            await Task.Delay(Timeout.Infinite, cts.Token);  // an API that takes the token31        }32        catch (OperationCanceledException e)33        {34            log.Add("Task.Delay threw " + e.GetType().Name);35        }36        return log;37    }38}

Timeouts, and telling them apart

To give one operation a deadline that also respects the client, link two sources:

using var cts = CancellationTokenSource.CreateLinkedTokenSource(ct);
cts.CancelAfter(TimeSpan.FromSeconds(5));
await pricing.QuoteAsync(order, cts.Token);

The linked token is cancelled when either parent is. An exception filter then tells you which one fired:

1public static class Solution2{3    static string Attempt(bool clientLeaves, bool timeoutFires)4    {5        using var client = new CancellationTokenSource();     // stands in for RequestAborted6        using var timeout = new CancellationTokenSource();    // stands in for CancelAfter7        using var linked = CancellationTokenSource.CreateLinkedTokenSource(client.Token, timeout.Token);8 9        if (timeoutFires) timeout.Cancel();10        if (clientLeaves) client.Cancel();11 12        try13        {14            linked.Token.ThrowIfCancellationRequested();15            return "completed";16        }17        catch (OperationCanceledException) when (client.IsCancellationRequested)18        {19            return "client went away: stop quietly";20        }21        catch (OperationCanceledException)22        {23            return "timed out: return 504";24        }25    }26 27    public static List<string> Run() => new()28    {29        Attempt(clientLeaves: false, timeoutFires: false),30        Attempt(clientLeaves: false, timeoutFires: true),31        Attempt(clientLeaves: true, timeoutFires: false),32    };33}

The same token pattern runs a background service: ExecuteAsync receives a stoppingToken that is cancelled when the host shuts down. Cancellation is just as cooperative there: a worker loop that never checks the token, or never passes it to the Task.Delay between rounds, keeps shutdown waiting.

Common mistakes

• Calling .Result on an async call inside a handler. It works in development and starves the pool under production load.
• Accepting a CancellationToken and not passing it on. The client has gone, and the database query still runs to completion.
• Passing the request token to work that must finish once started, such as recording a payment that already succeeded. Use CancellationToken.None there.
• Starting Task.Run(...) from a handler with the request's scoped services. The request ends, the scope disposes the DbContext, and the background work fails with ObjectDisposedException. Hand the work to a queue and a hosted service instead.

What interviewers ask

• Why is .Result dangerous in ASP.NET Core if there is no deadlock? It holds a thread pool thread while waiting; under load that is thread pool starvation.
• The user closes the browser tab mid-request. What happens to your query? Only what you wired up: RequestAborted is cancelled, and the query stops only if the token was passed down.
• A linked token source with , and an exception filter to tell the timeout from a client disconnect.