Investigate an endpoint that times out under concurrency even though individual SQL queries are fast.

• Use a disposable database with a deliberately small test pool.
• Bound concurrency and test duration.
• Measure acquisition separately from query execution.
• Restore service health before deeper production diagnosis.

I separate evidence: fast database commands plus slow connection acquisition points to pool pressure rather than query execution. The code fix makes ownership explicit with await using, including early returns and exceptions.

[Fact]
public async Task Leaked_branch_exhausts_a_small_pool_but_disposal_recovers()
{
    await using var database = await PostgresFixture.StartAsync(
        maxPoolSize: 2,
        connectionTimeoutSeconds: 1);
    var leaked = new List<DbConnection>();

    try
    {
        leaked.Add(await OpenAndReturnEarlyAsync(database.DataSource));
        leaked.Add(await OpenAndReturnEarlyAsync(database.DataSource));

        await Assert.ThrowsAsync<NpgsqlException>(async () =>
            await database.DataSource.OpenConnectionAsync());
    }
    finally
    {
        foreach (var connection in leaked)
            await connection.DisposeAsync();
    }

    var correctedCalls = Enumerable.Range(0, 20)
        .Select(_ => ExecuteHealthyBranchAsync(database.DataSource));

    await Task.WhenAll(correctedCalls).WaitAsync(TimeSpan.FromSeconds(10));
    Assert.Equal(0, database.CheckedOutConnections);
}

// Deliberately broken reproduction: an early return transfers no ownership
// and leaves the opened connection checked out.
private static async Task<DbConnection> OpenAndReturnEarlyAsync(
    DbDataSource dataSource) =>
    await dataSource.OpenConnectionAsync();

private static async Task ExecuteHealthyBranchAsync(DbDataSource dataSource)
{
    await using var connection = await dataSource.OpenConnectionAsync();
    await using var command = connection.CreateCommand();
    command.CommandText = "SELECT 1";
    await command.ExecuteScalarAsync();
}

The fixture must use a disposable PostgreSQL instance and expose pool metrics only to the test. The failing half proves the acquisition timeout; the corrected half proves that deterministic disposal restores the pool under repeated use.

The production evidence chain is request concurrency, connection acquisition duration, active/idle pool counts, database sessions, and recent code changes. A focused isolated load test can prove the fix; increasing pool size alone only delays exhaustion.

• Early return before command execution.
• An exception occurs while reading.
• Cancellation interrupts connection acquisition.
• One downstream dependency holds transactions open.

• Use a low pool maximum in a disposable test environment.
• Assert all tasks finish after the fix.
• Observe pool metrics returning to baseline.
• Keep the reproduction bounded and cancellable.

• Blaming slow SQL when acquisition is slow.
• Increasing pool size without fixing ownership.
• Opening connections without deterministic disposal.
• Load-testing a shared local or production database.