Bits of .NET

How a single line of Task.Run can turn your high-performance C# application into a production time bomb.

For years, C# has been marketed as a “safe” and “high-level” language. Garbage collection, async/await, dependency injection — all designed to protect developers from low-level mistakes.

And yet…

Some of the most expensive production failures I’ve seen in modern .NET systems come from developers who think they’re doing the right thing. Let’s talk about the mistake that looks harmless, passes code review, and slowly destroys performance.

---

The Illusion of Safety in Modern C#

Consider this clean, modern-looking controller:

public async Task<IActionResult> GetUsers()
{
    var users = await _repository.GetUsersAsync();
    return Ok(users);
}

But the danger lurks beneath. What if GetUsersAsync() is implemented like this?

public async Task<List<User>> GetUsersAsync()
{
    // WARNING: This is a thread pool time bomb
    return Task.Run(() =>
    {
        using var connection = new SqlConnection(_connectionString);
        connection.Open(); // Blocking I/O

        var command = new SqlCommand("SELECT * FROM Users", connection);
        using var reader = command.ExecuteReader(); // Blocking I/O

        var users = new List<User>();
        while (reader.Read()) { users.Add(Map(reader)); }
        return users;
    });
}

Congratulations. You just built a thread pool time bomb.

Why This Works… Until It Doesn’t

On your local machine, everything feels fine. In production, under real load, the mask falls off:

• Requests hang indefinitely while the CPU remains idle.
• Latency spikes without a corresponding increase in traffic.
• Cloud orchestrators (K8s/IIS) restart the app due to “Random” health check failures.

The Core Problem: Async ≠ Non-Blocking

The misconception is that async/await magically handles everything. In reality, they only release the thread if the underlying operation is truly asynchronous.

Wrapping blocking code in Task.Run() doesn’t solve the bottleneck; it simply relocates it. You are seizing a worker thread from the pool and forcing it to sit idle while waiting for the database response. This leads to Thread Pool Starvation.

The Correct Way: True Asynchronous I/O

Here is the same method, refactored to use non-blocking I/O all the way down:

public async Task<List<User>> GetUsersAsync()
{
    // 1. Asynchronous Resource Disposal
    await using var connection = new SqlConnection(_connectionString);
    
    // 2. Non-blocking Connection Opening
    await connection.OpenAsync();

    var command = new SqlCommand("SELECT * FROM Users", connection);
    
    // 3. True Async I/O - Thread is returned to the pool!
    await using var reader = await command.ExecuteReaderAsync();

    var users = new List<User>();
    
    // 4. Asynchronous Data Streaming
    while (await reader.ReadAsync())
    {
        users.Add(Map(reader));
    }
    return users;
}

What Exactly Changed?

The refactor shifts the application from Sync-over-Async to Pure Async. Here is the technical breakdown:

Feature	“Fake” Async (Task.Run)	“True” Async
Thread State	Blocked / Occupied	Released to Pool
Scalability	Bounded by Pool Size	High Concurrency Support
Waiting Mechanism	Active Waiting (Blocking)	Passive Waiting (Event-driven)

Final Thought

Modern C# gives you incredible power, but it also provides enough rope to quietly hang your system’s performance. The most dangerous bugs are the ones that pass tests and code reviews, failing only when it matters most.

Stop wrapping. Start awaiting.