Implement safe tenant-specific context creation when EF Core DbContext pooling is enabled.

A context used for tenant A returns to the pool. A later tenant-B request leases it, and the scoped wrapper overwrites TenantId with B before any query executes. Missing tenant identity fails instead of reusing A.

• Default tenant state must fail closed.
• Assign tenant state every time a context is leased.
• Register the wrapper as scoped and the pooled factory as singleton infrastructure.
• Do not accept tenant identity directly from an untrusted request field.

DbContext pooling reuses the context instance, so OnConfiguring does not run once per request and custom mutable state needs explicit handling. I wrap the pooled factory in a scoped factory that resolves trusted tenant identity and sets it before returning the context. All tenant-aware consumers use the wrapper, making a missing assignment difficult to bypass.

public sealed class AppDbContext : DbContext
{
    public Guid TenantId { get; set; } = Guid.Empty;

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>()
            .HasQueryFilter(order =>
                TenantId != Guid.Empty &&
                order.TenantId == TenantId);
    }
}

public sealed class TenantDbContextFactory(
    IDbContextFactory<AppDbContext> pooledFactory,
    ITenantAccessor tenantAccessor)
{
    public async Task<AppDbContext> CreateAsync(
        CancellationToken cancellationToken)
    {
        var tenantId = tenantAccessor.RequiredTenantId;
        if (tenantId == Guid.Empty)
            throw new InvalidOperationException("A tenant is required.");

        var db = await pooledFactory.CreateDbContextAsync(cancellationToken);
        db.TenantId = tenantId;
        return db;
    }
}

// Registration: handlers receive TenantDbContextFactory, not the pooled factory.
services.AddPooledDbContextFactory<AppDbContext>(ConfigureDatabase);
services.AddScoped<TenantDbContextFactory>();

Pooling reduces context setup allocations but does not make a context concurrent or remove normal disposal. The global filter parameterizes the current tenant value. Tenant-isolation tests must alternate tenants across many leased contexts and use a relational test database or container rather than the in-memory provider alone.

• No authenticated tenant is available.
• Requests for tenants A and B alternate rapidly.
• A background process legitimately needs cross-tenant access.
• A handler accidentally injects the raw pooled factory.

• Alternate two tenants repeatedly to encourage pooled instance reuse.
• Assert missing tenant identity returns no data or fails before querying.
• Test cross-tenant records with identical business ids.
• Review dependency registration so tenant handlers cannot bypass the wrapper.

• Setting tenant state once in OnConfiguring.
• Defaulting to the previous or a global tenant when identity is missing.
• Trusting a tenant id from request JSON without authorization.
• Treating the global filter as the only tenant-security boundary.