When Your Background Job Retries Are Silently Stepping on Each Other

A .NET developer walks through a subtle concurrency bug where two retried background jobs—each processing a different customer order—end up mutating the same shared row in SQL Server because the retry logic re-runs against stale state. The issue surfaces only under transient failures (timeouts, deadlocks), making it easy to miss in tests. The fix involves optimistic concurrency with a row-version column and idempotent retry guards, ensuring retries either reprocess safely or fail fast. Real-world EF Core snippet included.