EF Core Pooling Defaults and Cross-Request State Retention

Entity Framework Core DbContext pooling, introduced in version 5.0, reuses context instances across requests to reduce allocation overhead. Production environments commonly enable pooling via service configuration, while local development often defaults to disabled or in-memory providers, obscuring state-related side effects. When pooling is active, change-tracking state from prior requests may persist, causing unexpected entity updates, concurrency violations, or schema interpretation drift when combined with migrations and model caching. This environment-dependent behavior raises questions about the implicit assumptions developers hold regarding context lifecycle and state isolation.

What mechanisms does EF Core use to reset or preserve change-tracking state between pooled context lifetimes? How do the default PoolingBehavior values differ between development and production service configurations, and which configuration patterns prevent cross-request state leakage without disabling pooling entirely? What guardrails ensure thread-safe access and model consistency when DbContext pooling is enabled in a multi-request production workload?