ChannelDbConnectionPool

it might be good to add some documentation on how this class works and how this is different than the WaitHandleDbConnectionPool.

These ??= comments are a bit misleading. At line 466 we don't know whether or not we got an idle connection. We only know that if we hit the await part. Maybe this would be clearer as If we didn't find ..., then try to ....

How long does this test take to run? Does the runtime recover from this gracefully, and the parallel and subsequent tests run fine?

Is there a way to perform the argument checks without the huge allocation work?

Is it actually reasonable to have 2 billion slots?

Maybe we want an internal static property that defaults to a reasonable max slots, say 10,000. Apps would use that value, and you can confirm it in a test. But this test could set it much smaller to test the limit checks, and then reset it back.

I think I'd rather just remove this test. Having a pool of Int.MaxValue capacity doesn't make sense. Our biggest customers in azure aren't using more than a few thousand. This test is really only exercising OutOfMemory exception throwing, we can trust the runtime to do that properly.

You've already sufficiently verified this in the above tests.

Modified to construct a large pool, no longer covered after removing the test above.

These callbacks should track how many times they are called, and then you verify expectations below.

For createCallback, you could also save the connection it returns and verify that the same instance is returned from Add().

I think these callbacks should also verify they are called with the expected arguments

MockDbConnectionInternal expectedConnection = new();

var connection = poolSlots.Add(
  createCallback: (state) =>
  {
    Assert.Equal("test", state);
    return expectedConnection;
  },
  ...);

Assert.Same(connection, expectedConnection);

There is a test that specifically checks that callbacks receive the proper state value.

For this particular test, you don't expect the cleanupCallback to be called, so its body could be an Assert.Fail() instead of a counter.

As mentioned above, it's important to count the number of calls to these callbacks rather than just tracking if they've been called.

Strictly speaking, you don't know if TryRemove() removed the correct connection. You're verifying that it remove a connection (indirectly via the reservation count).

Not sure if there's a nice way to test what you actually describe.

I added a test that covers removing the same connection twice when another connection is also in the slots. The second remove should fail and reservation count should remain at 1. It shows that the slots distinguish between connections.

Why would connections[index] be null here?

removed

Let's enable nullable.

You don't document this exception in the Add() API, which I think is fine. Your API says "Don't pass null for the callbacks", which means callers should expect undefined behaviour if they misuse your API.

Maybe add a comment to this test noting the above. It's not testing any API promise, but rather confirming undefined behaviour.

Removed this test. Like you said, it's enforced by the type system.

This could benefit from a configurable max.

Removed in favor of a large capacity test.