Which blocking calls cause problems in ASP.NET Core, how do you find them, and what should replace them?

1. Waiting vs computing

The distinction matters because Task.Run doesn't fix waiting (see async-over-sync), and long CPU work needs capacity planning, not async.

2. Middleware and filters

// WRONG
app.Use((ctx, next) => { Audit(ctx); next(ctx).Wait(); return Task.CompletedTask; });

// RIGHT
app.Use(async (ctx, next) =>
{
    await AuditAsync(ctx, ctx.RequestAborted);
    await next(ctx);
});

Synchronous filter interfaces are fine for CPU logic; for anything that touches the database, cache or HTTP, implement IAsyncActionFilter / IAsyncAuthorizationFilter.

3. Logging

• Built-in providers (console, debug) queue messages on a background thread, but when the queue is full, logging calls block until there's space. Under very high log volume, that turns logging into a blocking call.
• Third-party sinks (Serilog, NLog) may write synchronously unless configured with async/batching wrappers.
• Avoid logging full request/response bodies on hot paths; use sampling and levels.

4. Database drivers and "fake async"

Modern providers (Microsoft.Data.SqlClient, Npgsql, MySqlConnector) implement real async I/O. Some older providers implement ...Async methods by running the sync version, which still blocks. The method name proves nothing; check docs and look at stacks under load.

5. Streaming instead of buffering

app.MapPost("/photos", async (HttpRequest req, BlobContainerClient blobs, CancellationToken ct) =>
{
    var blob = blobs.GetBlobClient($"{Guid.NewGuid()}.jpg");
    await blob.UploadAsync(req.Body, overwrite: false, ct);   // streams; no full in-memory copy
    return Results.Created(blob.Uri, null);
});

Streaming with async I/O fixes both blocking and memory spikes for large payloads (configure MaxRequestBodySize deliberately).

6. Version notes

7. Try it yourself

1. Call /upload-bad from the code example and observe InvalidOperationException.
2. Enable AllowSynchronousIO, load-test with a throttled client (e.g. curl --limit-rate 10k in parallel), and watch pool metrics; then switch to /upload.
3. Add Thread.Sleep(200) in an endpoint, load-test, then replace with await Task.Delay(200).
4. Write a middleware that does next(ctx).Wait() and observe its effect under load.
5. Enable CA1849 in .editorconfig (dotnet_diagnostic.CA1849.severity = warning) and fix findings.
6. Configure a logging sink without batching, log heavily under load, and capture stacks to see logging frames.

using System.Text.Json;

var builder = WebApplication.CreateBuilder(args);
// Do NOT do this to silence errors:
// builder.WebHost.ConfigureKestrel(o => o.AllowSynchronousIO = true);
var app = builder.Build();

// BAD (throws by default; blocks if AllowSynchronousIO is enabled)
app.MapPost("/upload-bad", (HttpRequest request) =>
{
    using var reader = new StreamReader(request.Body);
    string text = reader.ReadToEnd();
    return text.Length;
});

// GOOD: async body reading, async delay, async lock
var gate = new SemaphoreSlim(1, 1);
app.MapPost("/upload", async (HttpRequest request, CancellationToken ct) =>
{
    using var reader = new StreamReader(request.Body);
    string text = await reader.ReadToEndAsync(ct);

    await gate.WaitAsync(ct);
    try
    {
        await Task.Delay(10, ct); // stands in for async I/O under a shared limit
    }
    finally
    {
        gate.Release();
    }
    return Results.Ok(new { Length = text.Length });
});

// GOOD: model binding / ReadFromJsonAsync are already async
app.MapPost("/orders", async (HttpRequest request, CancellationToken ct) =>
{
    var order = await request.ReadFromJsonAsync<JsonElement>(ct);
    return Results.Accepted(value: order.GetProperty("id").GetInt32());
});

app.Run();