Introduction

In modern ASP.NET, the usual way to cancel database work when the client disconnects is to propagate the request cancellation token into the database call. In ASP.NET Core that token is HttpContext.RequestAborted, and once it is passed into EF Core or ADO.NET async APIs, the database operation can be cancelled when the browser goes away.

Use the request cancellation token

In ASP.NET Core, every request has a cancellation token:

1public async Task<IActionResult> GetUsers(CancellationToken cancellationToken)
2{
3    var users = await _dbContext.Users.ToListAsync(cancellationToken);
4    return Ok(users);
5}

Model binding can supply the request token directly through the action parameter. You can also read it explicitly from HttpContext.RequestAborted.

var token = HttpContext.RequestAborted;

The key point is that cancellation has to be passed down the stack. ASP.NET cannot magically interrupt a database driver call that never received a token.

EF Core example

With EF Core, most async query APIs accept a CancellationToken.

1public async Task<List<Order>> LoadOrdersAsync(CancellationToken token)
2{
3    return await _dbContext.Orders
4        .Where(o => o.Status == "Open")
5        .ToListAsync(token);
6}

If the browser disconnects and the request token is cancelled, EF Core can propagate that to the provider.

Raw ADO.NET example

The same idea applies if you use SqlCommand directly.

1using var connection = new SqlConnection(connectionString);
2await connection.OpenAsync(token);
3
4using var command = new SqlCommand("SELECT * FROM Orders", connection);
5using var reader = await command.ExecuteReaderAsync(token);

Here again, cancellation only works because the token is passed into the async ADO.NET methods.

Classic ASP.NET versus ASP.NET Core

The best answer depends on the framework generation. In ASP.NET Core, RequestAborted is the normal path. In older ASP.NET, there were APIs such as Response.ClientDisconnectedToken, but the experience was less consistent and more framework-specific.

So if you are reading older advice, separate it by platform:

• ASP.NET Core: use HttpContext.RequestAborted
• classic ASP.NET: use the older disconnect token mechanisms available in that runtime

Do not mix the two models mentally.

Cancellation is cooperative, not magical

Even with the right token, cancellation is cooperative. The framework signals that the request has been aborted, but the lower layers have to honor it.

That means:

• use async APIs that accept tokens
• pass the token all the way down
• avoid wrapping long synchronous work that cannot observe cancellation

If part of the stack ignores cancellation, the query may keep running anyway.

What to do in repository or service layers

Do not stop at the controller. Accept a CancellationToken in service and repository methods too.

1public Task<List<Order>> GetOpenOrdersAsync(CancellationToken token)
2{
3    return _dbContext.Orders
4        .Where(o => o.Status == "Open")
5        .ToListAsync(token);
6}

That keeps the cancellation signal alive through the whole request path.

Common Pitfalls

• Detecting client disconnects but never passing the cancellation token into the database call.
• Using synchronous database APIs that cannot cooperate with cancellation.
• Assuming ASP.NET will automatically kill a running SQL query with no support from the data provider.
• Mixing old ASP.NET guidance with ASP.NET Core request-cancellation patterns.
• Forgetting to thread the cancellation token through service and repository methods.

Summary

• In ASP.NET Core, use HttpContext.RequestAborted or a bound CancellationToken.
• Pass that token into EF Core or ADO.NET async methods.
• Cancellation only works if the lower layers actually observe the token.
• Keep the token flowing through controllers, services, and repositories.
• Distinguish modern ASP.NET Core guidance from older classic ASP.NET APIs.