Cancellation is part of the request contract

When a browser navigates away or a client times out, ASP.NET Core signals the request cancellation token. Pass it to database and HTTP operations so work can stop when its result is no longer needed.

[HttpGet]
public async Task<ActionResult<OrderResponse>> Get(Guid id, CancellationToken ct)
{
    var order = await sender.Send(new GetOrderQuery(id), ct);
    return order is null ? NotFound() : Ok(Map(order));
}

Propagate instead of replacing

A handler should forward the supplied token to EF Core, HttpClient, and other cancellable I/O. Creating a new token or using CancellationToken.None in the middle of a request breaks the cancellation chain. Background work has a different lifetime and should use its host stopping token.

Cancellation is not a successful result

Do not catch OperationCanceledException and return an empty success response. Let the request pipeline distinguish a canceled operation from a validation error or an unexpected failure. Cleanup belongs in finally or disposal paths that run for both success and cancellation.

Avoid blocking async work

Calling .Result or .Wait() can occupy request threads and can deadlock in contexts that require the blocked thread to resume continuations. Keep the call chain asynchronous; use Task for normal asynchronous methods and reserve ValueTask for measured, frequently synchronous hot paths.

Interview takeaway

Trace cancellation from the HTTP action to the final I/O call. Then explain what the code does when cancellation arrives during a transaction or external request.