Info

In SERVER-110003, we changed the "state" from a set of unrelated boolean values to a mutually exclusive enum, as this models the state better. However, we inadvertently allowed for a state transition from kFailed to kExpired if we detected that the pool became expired. Normally this would be okay and the pool would just be delisted, but due to the way ShardingTaskExecutorPoolController is implemented, the pool is only allowed to be shut down if every pool the "group" (i.e. replica set) is also expired. If the controller doesn't allow the pool to be delisted, it'll proceed to spawnConnections to attempt to establish a new connection. This loop will repeat endlessly because _lastActiveTime will only be updated when something tries to get a connection, but all this is happening in the background to satisfy minPoolSize. I was able to repro this by forcing the LimitController (used in the C++ tests) to always return false for canShutdown. By forbidding a transition out of kFailed to kExpired, it solves the problem. To ensure we can still expire even if the pool is currently failed, we may want to track expiration separately from the main state of the pool, similar to the pre-SERVER-110003 behavior.

Top User Comments

xgen-internal-githook commented on Fri, 3 Apr 2026 03:21:32 +0000: Author: {'name': 'Didier Nadeau', 'email': 'didier.nadeau@mongodb.com', 'username': 'nadeaudi'} Message: SERVER-123339 Separate expired state from the connection pool health (#51053) Co-authored-by: Mike Nugent Co-authored-by: Joseph Prince GitOrigin-RevId: e8d9b5cb0591c1f21a71532ac9b9fbdaf8f74458 Branch: master https://github.com/mongodb/mongo/commit/7b6adf5671e9d2099155fde7870014fa90eeaf92

Steps to Reproduce