Three related pool-accounting defects found by stress-testing SessionPool against fake listeners:
acquire() spends none of its acquire_timeout budget when the growth branch fails. When open_session() fails, acquire() returns the error immediately (measured 198us against a 5s budget; 4136 of 4800 acquires failed instantly under stress while sessions were circulating). The same happens when the USE replay in hand_out fails — it discards the remaining idle candidates instead of retrying the loop.
live is decremented outside the state lock at several sites, and the decremented value is exactly the predicate parked waiters re-evaluate, so Condvar notifications can be lost. The comment "Only mutated while holding state" no longer matches the code. Measured stalls track acquire_timeout exactly (300ms → 305ms, 1000ms → 1.005s).
acquire_timeout = Duration::MAX panics on Instant::now() + acquire_timeout overflow before the lock is taken. There is no "never time out" option, and Duration::MAX is the natural way to ask for one.
Fix: on growth/hand-out failure, re-take the lock, decrement live under it, notify, and continue the loop (bounded by the original deadline); use a saturating deadline (checked_add) so Duration::MAX means "wait without timeout".
Three related pool-accounting defects found by stress-testing
SessionPoolagainst fake listeners:acquire()spends none of itsacquire_timeoutbudget when the growth branch fails. Whenopen_session()fails,acquire()returns the error immediately (measured 198us against a 5s budget; 4136 of 4800 acquires failed instantly under stress while sessions were circulating). The same happens when theUSEreplay inhand_outfails — it discards the remaining idle candidates instead of retrying the loop.liveis decremented outside thestatelock at several sites, and the decremented value is exactly the predicate parked waiters re-evaluate, so Condvar notifications can be lost. The comment "Only mutated while holdingstate" no longer matches the code. Measured stalls trackacquire_timeoutexactly (300ms → 305ms, 1000ms → 1.005s).acquire_timeout = Duration::MAXpanics onInstant::now() + acquire_timeoutoverflow before the lock is taken. There is no "never time out" option, andDuration::MAXis the natural way to ask for one.Fix: on growth/hand-out failure, re-take the lock, decrement
liveunder it, notify, and continue the loop (bounded by the original deadline); use a saturating deadline (checked_add) soDuration::MAXmeans "wait without timeout".