Architectural considerations for Idempotency Middleware, Distributed Locks, and ⁠RequestAborted⁠ in ASP.NET 8

[rodrigo-oliv-ciandt]

Hi everyone,
I’m looking to get some architectural insights from the community regarding the intersection of ASP.NET Core middleware, distributed locking, and EF Core 8 execution strategies—specifically around handling client disconnects (⁠HttpContext.RequestAborted⁠).
The Context
In our distributed architecture (DDD-based), we are using ASP.NET 8 with an Idempotency Middleware. The standard flow for mutating requests (POST/PUT) is:

1. Middleware intercepts the request and checks the ⁠Idempotency-Key⁠ header.
2. It acquires a distributed lock (e.g., via Redis) to prevent concurrent identical requests.
3. It checks if a cached response already exists for this key. If so, it short-circuits.
4. If not, it invokes ⁠next(context)⁠, passing the request down to the controllers/handlers where EF Core 8 processes the domain logic and commits the transaction.
5. On success, the middleware caches the response and releases the lock.
   The Problem
   The architectural friction arises when a client drops the connection, triggering the ⁠HttpContext.RequestAborted⁠ cancellation token.
   If we flow ⁠context.RequestAborted⁠ all the way down to EF Core, the database operation is correctly cancelled and rolled back. However, the Idempotency Middleware might be interrupted before it can safely release the distributed lock or update the idempotency state store (e.g., marking the request as "failed" rather than "in-progress"). This can leave that specific idempotency key locked or in a zombie state until the distributed lock's TTL expires, artificially blocking retries from the client.
   Conversely, if we decouple the cancellation token (using a separate ⁠CancellationTokenSource⁠ for the background lock-release operation), we risk exhausting ThreadPool resources if clients aggressively disconnect and retry, as the application continues processing orphaned requests.
   Questions for the community:
6. Request Lifecycle vs. Business Lifecycle: In an ASP.NET 8 pipeline, what is the recommended pattern for decoupling the HTTP request cancellation from critical state-management operations (like releasing a distributed lock) within a middleware?
7. Resilience Integration: With the introduction of ⁠Microsoft.Extensions.Resilience⁠ (Polly v8) in .NET 8, is there a cleaner way to handle this at the pipeline level rather than custom middleware? Perhaps wrapping the endpoint execution in a resilience pipeline that guarantees execution of the idempotency teardown regardless of ⁠RequestAborted⁠?
8. DbContext Scoping: If the middleware needs to update a database-backed idempotency record after the request is aborted, how are you managing the ⁠Scoped⁠ DbContext injection, given that the DI scope might be disposed when the HTTP context aborts?
   I’d appreciate any thoughts, patterns, or experiences you've had dealing with this specific boundary between ASP.NET Core's request lifecycle and distributed idempotency.
   Thanks!

[rodri-oliveira-dev]

I would approach this by separating request cancellation, business transaction consistency, and idempotency state management. They have different lifecycle and reliability requirements.

1. RequestAborted and cleanup

A client disconnect does not automatically terminate middleware execution. It signals cancellation, and downstream operations may throw OperationCanceledException.

An awaited finally block can still perform cleanup using a short-lived, independent cancellation token:

try
{
await next(context);
}
finally
{
using var cleanupCts =
new CancellationTokenSource(TimeSpan.FromSeconds(3));
try
{
await distributedLock.ReleaseAsync(
cleanupCts.Token);
}
catch (Exception ex)
{
logger.LogError(
ex,
"Unable to release the distributed lock");
}
}

This is an illustrative pattern, not a complete idempotency implementation.

The release must be ownership-aware (for example, an atomic compare-and-delete in Redis). A plain DEL could accidentally release a lock acquired by another request after the original lease expired.

The lock also needs a TTL because finally cannot guarantee execution during process termination.

2. Cancellation does not guarantee transaction rollback

This is arguably the most important distinction.

EF Core forwards cancellation to the database provider, but cancellation is cooperative. If cancellation or connection failure occurs around transaction commit, the outcome may be unknown.

Therefore, I would avoid automatically marking an idempotency record as Failed simply because RequestAborted was triggered.

A safer model is:

• InProgress: the operation has been claimed.
• Completed: the committed outcome is known and can be replayed.
• Unknown or an expired claim: the operation needs reconciliation before a retry is allowed to execute business logic again.

When possible, persist the idempotency completion record in the same database transaction as the business changes, with a unique constraint protecting the operation identity. This makes the committed business outcome and its completion marker atomic.

A Redis response cache can then be treated as a derived optimization rather than the sole source of truth.

3. DbContext and request-scoped services

The DI request scope is not immediately disposed merely because RequestAborted is signaled. It normally remains valid until request processing finishes.

For short cleanup awaited within the middleware, using request-scoped services can be appropriate, provided their state remains usable.

For work intentionally detached from the request, use a BackgroundService or a bounded queue and create a fresh scope with IServiceScopeFactory. Do not capture HttpContext or a request-scoped DbContext in fire-and-forget tasks.

4. Polly / Microsoft.Extensions.Resilience

Polly can help with transient failures, timeouts, and resilience policies, but it does not provide transactional guarantees or replace deterministic cleanup.

I would be particularly cautious about retrying the complete HTTP operation. If the first attempt committed successfully but its result was lost, replaying the handler could duplicate business effects unless those operations are independently idempotent.

My preferred architecture

Use a distributed lock only as a short-lived concurrency optimization, with ownership tokens and expiration. Let the persistent idempotency record enforce replay safety, and use a bounded, request-independent cancellation budget for cleanup.

For operations whose outcome remains uncertain, reconcile the persisted business state before allowing another attempt.

The essential invariant is:

A client disconnect must never turn an already committed business operation into an apparently unprocessed request.

Relevant references:

• ASP.NET Core — Use HttpContext
• EF Core — Connection resiliency
• ASP.NET Core — Hosted services
• Redis — Distributed locks