Resilient Execution Strategies: Retryable Failures, Idempotency, and Transaction Delegates

Learning outcomes

An execution strategy is EF/provider logic that can replay database operations after failures classified as transient. It is not a generic catch/retry loop, and it is not optimistic-concurrency resolution. When the application starts its own transaction, replay must encompass the entire transaction so the unit can be reconstructed safely.

1. Provider retries classify infrastructure failures, not business conflicts

Never copy EnableRetryOnFailure to providers that do not expose the same extension or error taxonomy. The SQL Server provider includes a retrying execution strategy; the mandatory SQLite lab focuses on the API contract and local transaction safety without pretending it is Azure SQL.

2. Inspect the strategy you actually configured

var strategy = db.Database.CreateExecutionStrategy();Console.WriteLine(strategy.GetType().FullName);Console.WriteLine($"RetriesOnFailure: {strategy.RetriesOnFailure}");

Record this output in the lab. If the SQLite strategy is non-retrying, that is useful evidence—not a missing feature to paper over. A production SQL Server configuration can opt into connection resiliency:

options.UseSqlServer(    connectionString,    sql => sql.EnableRetryOnFailure());

Do not freeze universal retry counts or delays. Provider defaults and workload tolerance are part of production configuration, monitoring, and incident design.

3. Deliberately wrong under a retrying strategy: start a transaction outside replay

await using var tx = await db.Database.BeginTransactionAsync(ct);// Under a retrying strategy, EF cannot replay this user transaction automatically.await db.SaveChangesAsync(ct);await tx.CommitAsync(ct);

With a retrying execution strategy such as SQL Server’s, EF documents an InvalidOperationException explaining that user-initiated transactions are not supported in that form. A command cannot be retried independently if correctness requires replaying earlier commands in the same transaction.

4. Repair: the transaction is inside the strategy delegate

var strategy = db.Database.CreateExecutionStrategy();await strategy.ExecuteAsync(async () =>{    await using var attempt = await factory.CreateDbContextAsync(ct);    await using var tx = await attempt.Database.BeginTransactionAsync(ct);    var order = await attempt.WorkOrders.SingleAsync(x => x.Id == id, ct);    order.ReviseSummary("retry-safe transaction attempt");    order.AdvanceRevision();    await attempt.SaveChangesAsync(ct);    attempt.Set<OutboxMessage>().Add(new OutboxMessage    {        Id = messageId,                  // stable client-generated identity        OccurredUtc = occurredUtc,        Type = "WorkOrderChanged",        PayloadJson = payload    });    await attempt.SaveChangesAsync(ct);    await tx.CommitAsync(ct);});

The delegate describes the unit that can be replayed. A fresh context per attempt prevents a failed connection/transaction from contaminating a later attempt. Stable inputs such as messageId are created outside the delegate so each replay represents the same logical operation.

5. Commit can fail ambiguously

If the connection drops while commit is occurring, the client may not know whether the server committed. Replaying as though rollback occurred can duplicate work if the first commit actually succeeded. EF’s connection-resiliency guidance explicitly calls this the idempotency/commit-unknown problem.

6. Verification pattern with AcceptAllChanges deferred

var strategy = db.Database.CreateExecutionStrategy();await strategy.ExecuteInTransactionAsync(    db,    operation: (context, token) =>        context.SaveChangesAsync(acceptAllChangesOnSuccess: false, token),    verifySucceeded: (context, token) =>        context.Set<OutboxMessage>()            .AsNoTracking()            .AnyAsync(x => x.Id == messageId, token));db.ChangeTracker.AcceptAllChanges();

acceptAllChangesOnSuccess: false keeps the tracked state replayable until the strategy has determined success. This is advanced infrastructure code: test it with deliberate failure injection and keep the verification key unique and meaningful.

7. The strategy may buffer result sets

EF’s connection-resiliency documentation notes that enabling retries causes EF to internally buffer result sets so a query can be replayed. That can materially increase memory for large streaming queries. Retry configuration therefore affects query memory behavior as well as writes—another reason not to enable a setting by cargo cult.

8. Hands-on lab

1. Print the mandatory SQLite execution-strategy type and RetriesOnFailure.
2. Execute a simple strategy delegate and verify normal behavior even if the provider is non-retrying.
3. Write a unit/integration seam that injects a fake/test execution strategy or fault wrapper to prove the transaction delegate can run more than once without producing a second logical outbox ID.
4. Keep messageId outside the replay delegate and assert uniqueness/idempotency.
5. Implement the documented ExecuteInTransactionAsync verification shape on the disposable outbox table.
6. For optional SQL Server, enable retries and reproduce the user-transaction InvalidOperationException; then move the transaction into the delegate.
7. Record conflict exceptions separately and prove your retry classifier does not treat DbUpdateConcurrencyException as transient infrastructure.
8. Document memory implications before enabling retries around very large result streams.

9. Production judgment and bridge

Retry only failures the provider classifies as transient, replay the correct unit, and make ambiguous commits observable/idempotent. Chapter 14’s next lesson keeps one local transaction but spreads work across multiple EF contexts and raw ADO.NET, showing that transaction coordination and change-tracker coordination are separate problems.

Authoritative references

• Connection Resiliency - EF Core — provider execution strategies, user-transaction delegate pattern, ambiguous commits, and verification.
• Using Transactions - EF Core — interaction between transactions and execution strategies.
• SQL Server EF Core provider — provider-specific connection resiliency configuration boundary.
• IExecutionStrategy API — execution strategy contract and RetriesOnFailure.
• Handling Concurrency Conflicts - EF Core — business-state conflicts that must not be conflated with transient retries.