EF Core safety

Understand the entity model, mappings, query shape, indexes, tracking needs, transaction boundary, concurrency behavior, and migration history before editing.

• Keep DbContext scoped to a unit of work and never use one instance concurrently. Await each operation before starting the next.
• Project only needed data; avoid accidental N+1 queries, client evaluation assumptions, unbounded result sets, premature materialization, and unnecessary tracking (AsNoTracking for read-only work when consistent with the repository).
• Propagate cancellation to async database calls. Use async methods for request-path I/O.
• Make transaction boundaries explicit when multiple writes must be atomic. Account for execution-strategy retries and external side effects; do not assume a database transaction covers remote calls.
• Handle optimistic concurrency deliberately when lost updates matter. Design retry/merge behavior rather than blindly overwriting.
• Treat migrations as production contracts: inspect generated operations, data loss, locks, defaults/backfills, deployment ordering, mixed-version compatibility, and rollback/roll-forward strategy.

Do not introduce a custom retry loop merely because a database failure might be transient. Add retry behavior only when explicitly requested or already required/configured by the architecture, prefer the provider's EF Core execution strategy, and verify idempotency, transaction boundaries, duplicate-write safety, timeout budget, bounded attempts, cancellation, and permanent-error classification.

Validate query behavior and SQL/performance when risk warrants it. Test provider-specific behavior with the appropriate provider; do not assume an in-memory provider reproduces relational semantics.

For production schema changes, prefer an expand/backfill/contract sequence where mixed application versions must coexist. Review backfill batching, locks, resumability and compatibility before deployment. Verify migrations and constraints against the actual provider when practical.