I'm under the impression that this can be already achieved through PoolOptions#factory; I'm happy either way, but it we want to land it in core I'd suggest to assign a more explicit name like ttl or something.

On top, consider the possibility of verify/preempt the client upon a request, so we reduce the surface for possible race conditions between removal and new upcoming request.

I'm under the impression that this can be already achieved through PoolOptions#factory;

I would have gone down that route but i'm not sure how to remove a client from the pool. That doesn't seem to be exposed anywhere in Pool.

I updated the logic to remove clients in the getDispatcher call when the TTL has passed. This should not add any significant overhead.

Ugh, I was trying to rebase my fork to hopefully fix the test issues and screwed up. Please re-approve when you get the chance. I squashed it down to one commit so it will be cleaner.

Hi @metcoder95 Any idea why those tests might be failing? They don't seem related to may changes as far as I can tell.

Yeah, these are flaky tests that needs to be fixed; but are not related to your changes.

Is there a way to re-run them until they pass?

They will fail constantly. I hope I can have a fix soon

Hi @metcoder95 , I'm a bit bummed this didn't make it into the 7.9.0 release. What are the steps forward?