Implement a retriable stock-transfer transaction using EF Core's execution strategy.

• The execution strategy owns the complete transaction delegate.
• Create a fresh DbContext for each attempt.
• Protect logical replay with a unique transfer id.
• Do not include external side effects inside the retried delegate.

I obtain the provider strategy, then put context creation, transaction start, database changes, save, and commit inside its delegate. A fresh context avoids carrying uncertain tracked state into a retry. The transfer id is still essential because a connection failure around commit can make the outcome unknown.

public static async Task TransferStockAsync(
    IDbContextFactory<AppDbContext> contextFactory,
    TransferStock command,
    CancellationToken cancellationToken)
{
    await using var strategyContext =
        await contextFactory.CreateDbContextAsync(cancellationToken);

    var strategy = strategyContext.Database.CreateExecutionStrategy();

    await strategy.ExecuteAsync(async () =>
    {
        await using var db =
            await contextFactory.CreateDbContextAsync(cancellationToken);
        await using var transaction =
            await db.Database.BeginTransactionAsync(cancellationToken);

        if (await db.StockTransfers.AnyAsync(
            transfer => transfer.Id == command.TransferId,
            cancellationToken))
        {
            await transaction.CommitAsync(cancellationToken);
            return;
        }

        await InventoryTransfer.ApplyAsync(db, command, cancellationToken);
        db.StockTransfers.Add(StockTransfer.From(command));

        await db.SaveChangesAsync(cancellationToken);
        await transaction.CommitAsync(cancellationToken);
    });
}

Each attempt is a complete transactional unit. The unique transfer id must also exist as a database constraint because two concurrent first attempts can both pass the existence check. Retry counts, duration, and final failures should be observable so retries do not hide database saturation.

• The transient failure occurs before save, during save, or around commit.
• Two callers submit the same transfer id concurrently.
• The source lacks sufficient inventory.
• Cancellation occurs between database operations.

• Inject transient failures at several transaction stages in an isolated integration test.
• Run duplicate transfer ids concurrently and verify one logical result.
• Assert no external messages or HTTP calls occur inside the retry delegate.
• Verify the unique transfer constraint is present.

• Starting a manual transaction outside the execution strategy.
• Reusing one uncertain DbContext state across attempts.
• Assuming retries remove the need for idempotency.
• Repeating external side effects whenever the database delegate retries.