Mastering Long-Running Tasks in ASP.NET Core Without Blocking Requests

Let's be real: we've all written code that we knew was a ticking time bomb. For me, it was a reporting dashboard I built a few years ago. I thought I was being clever by utilizing async/await everywhere, assuming it freed up the threads. But when 100 users simultaneously requested a PDF report exporting a full year of transactions, the server didn't just slow down—it completely choked. Thread pool starvation hit, TCP sockets exhausted, and the application container crashed. It was a classic production nightmare.

The core issue is that even though await yields the worker thread back to Kestrel, the client connection is still held open. You're holding onto TCP connections, IIS application pools, and memory. If a client closes the tab because it's taking too long, the server keeps executing the heavy database queries anyway because nobody checks cancellation tokens.

In this article, we'll look at how to get these long-running tasks off the HTTP pipeline using .NET's built-in System.Threading.Channels, and the exact traps (like Scoped service lifetimes in Singletons) that will crash your app on startup.

Why You Shouldn't `await` Long Tasks Inline

Every HTTP request in ASP.NET Core is handled by Kestrel. When a request hits, Kestrel allocates a thread from the thread pool. Even if you use async/await to make the call non-blocking for CPU threads, the client browser is still hanging on the wire, keeping the TCP connection active.

Under a sudden traffic spike, your thread pool gets saturated. You'll run out of available TCP sockets or hit Kestrel limits, causing the server to throw 504 Gateway Timeouts. Plus, if a user gets annoyed, closes their browser tab, and walks away, the server keeps executing the heavy database queries anyway because there's no natural way to abort the task unless you perfectly passed and monitored a CancellationToken.

The Anti-Pattern: Awaiting Inline

Here is the classic pitfall to avoid:

[HttpPost("generate-report")]
public async Task GenerateReport()
{
  // BAD: Blocks the request socket for 10+ seconds while doing heavy PDF generation
  await _reportService.GenerateHeavyPdfAsync(); 
  
  return Ok("Report generated"); 
}

Solution: Queued Background Tasks

Instead of doing the work inline, the API controller should do two things: drop a small job payload into a queue, and immediately return a 202 Accepted status to the client, along with a task ID or status URL.

A background worker consumes the queue asynchronously. Here are the three main ways to handle this:

Implementing `Channel` (And Two Crucial Gotchas)

For single-instance apps, System.Threading.Channels is incredibly performant and thread-safe. We use a bounded channel because an unbounded one will grow indefinitely under load, eating up RAM until the OS kills the process.

public class BackgroundTaskQueue
  {
      private readonly Channel> _queue;

      public BackgroundTaskQueue(int capacity)
      {
          // BoundedChannelFullMode.Wait blocks the writer when the queue is full
          var options = new BoundedChannelOptions(capacity)
          {
              FullMode = BoundedChannelFullMode.Wait
          };
          _queue = Channel.CreateBounded>(options);
      }

      public async ValueTask QueueBackgroundWorkItemAsync(
          Func workItem)
      {
          if (workItem == null) throw new ArgumentNullException(nameof(workItem));
          await _queue.Writer.WriteAsync(workItem);
      }

      public async ValueTask> DequeueAsync(
          CancellationToken cancellationToken)
      {
          return await _queue.Reader.ReadAsync(cancellationToken);
      }
  }

Gotcha #1: The Scoped Service Trap

This is the most common mistake I see developers make when setting up a BackgroundService. Your background worker is registered as a Singleton. But database contexts (like Entity Framework's DbContext) are registered as Scoped. If you try to inject a Scoped service directly into the constructor of your Singleton BackgroundService, .NET will throw a dependency injection validation error on startup, preventing the host from even running.

If you disable validation (please don't), you'll end up sharing a single DbContext instance across multiple threads, causing database corruption and concurrency crashes. To avoid this, you must inject IServiceScopeFactory, create a scope manually inside your worker loop, and resolve the database context inside that scope:

// Inside your BackgroundService loop
using (var scope = _serviceScopeFactory.CreateScope())
{
    var dbContext = scope.ServiceProvider.GetRequiredService();
    await dbContext.ProcessReportAsync(taskId);
}

Gotcha #2: The In-Memory Queue Amnesia

In-memory queues like System.Threading.Channels are fast and require zero external dependencies, but they have one massive flaw: they have amnesia. If you deploy a new container to Kubernetes, restart your Docker container, or if IIS decides to recycle your application pool, everything currently sitting in the channel is wiped out.

If you are handling non-critical tasks like updating an activity log or pre-heating a cache, that's fine. But if you are processing credit card payments, sending invoice emails, or handling critical business transactions, do NOT use this in-memory channel. You need a durable, out-of-process queue like RabbitMQ, or a database-backed solution like Hangfire.

Ashish Kohli

Ashish Kohli is a senior backend engineer and systems architect specializing in cloud infrastructure and high-throughput .NET systems. With a passion for clean architecture, he spends his time designing distributed pipelines and optimizing database query performance.

Read more articles by this author