Summary
Three non-blocking observations about BaseSessionPool that came out of the reviews of #19 and #20. None of them is a crash or a leak on the normal path, so I did not fold them into those PRs; @CritasWang suggested collecting them in a single tracking issue.
Line references are against develop at a8ca4d2.
1. minPoolSize: 0 is silently coerced to 1
BaseSessionPool.ts:129 (and the cleanup floor at :373) read the setting as:
constminSize=this.config.minPoolSize||1;
0 || 1 is 1, so a caller who explicitly asks for minPoolSize: 0 gets one eagerly created session at init(), and cleanupIdleSessions then keeps one session alive forever rather than letting the pool drain to empty. In most pool implementations 0 means "create nothing up front, and allow the pool to go back to empty when idle", which is a reasonable ask for short-lived or cost-sensitive processes.
If 0 is intended to be legal, ?? instead of || would express it. If it is not intended to be legal, rejecting it in config validation would be clearer than silently changing it.
2. close() clears the wait queue without settling the waiters
close() at :505 ends with this.waitQueue.clear() (:525). The queued entries are the waiter callbacks themselves, so clearing the queue drops them without ever resolving or rejecting their promises.
A caller that is inside await pool.getSession() when another part of the application closes the pool therefore does not fail fast. It stays pending until the acquire timeout fires (waitTimeout, default 60000ms at :290) and then rejects with Timeout waiting for available session (:320) — which points at pool exhaustion rather than at the real cause. Rejecting each queued waiter during close() with a "pool is closed" error would make both the latency and the message correct.
3. A failed session.close() during idle cleanup orphans the connection
cleanupIdleSessions (:391 onward) deliberately removes a session from pool and idleSessionsbefore awaiting close(), which is correct — it prevents a concurrent getSession() from handing out a session that is about to be destroyed. But if close() rejects, the error is logged (:409) and nothing else happens: the session is already out of every pool structure, so its underlying connection is no longer referenced, never retried, and never counted anywhere.
That is not a leak in the common case — the RPC usually fails because the connection is already gone — but a transport-level failure would leave a real socket open with no owner. Keeping the session in a small "failed to close" set for a later retry, or at least counting it in a metric, would make the failure visible.
Not included
The getSession() create-branch race that also came up in the #19 review is already fixed on develop (:266-276 now locates the session by identity instead of shift()ing the front of the idle queue), so there is nothing left to track there.
I am happy to send a PR for any of these — please let me know which are worth changing and whether you would prefer them separately.
Summary
Three non-blocking observations about
BaseSessionPoolthat came out of the reviews of #19 and #20. None of them is a crash or a leak on the normal path, so I did not fold them into those PRs; @CritasWang suggested collecting them in a single tracking issue.Line references are against
developat a8ca4d2.1.
minPoolSize: 0is silently coerced to 1BaseSessionPool.ts:129(and the cleanup floor at:373) read the setting as:0 || 1is1, so a caller who explicitly asks forminPoolSize: 0gets one eagerly created session atinit(), andcleanupIdleSessionsthen keeps one session alive forever rather than letting the pool drain to empty. In most pool implementations0means "create nothing up front, and allow the pool to go back to empty when idle", which is a reasonable ask for short-lived or cost-sensitive processes.If
0is intended to be legal,??instead of||would express it. If it is not intended to be legal, rejecting it in config validation would be clearer than silently changing it.2.
close()clears the wait queue without settling the waitersclose()at:505ends withthis.waitQueue.clear()(:525). The queued entries are the waiter callbacks themselves, so clearing the queue drops them without ever resolving or rejecting their promises.A caller that is inside
await pool.getSession()when another part of the application closes the pool therefore does not fail fast. It stays pending until the acquire timeout fires (waitTimeout, default 60000ms at:290) and then rejects withTimeout waiting for available session(:320) — which points at pool exhaustion rather than at the real cause. Rejecting each queued waiter duringclose()with a "pool is closed" error would make both the latency and the message correct.3. A failed
session.close()during idle cleanup orphans the connectioncleanupIdleSessions(:391onward) deliberately removes a session frompoolandidleSessionsbefore awaitingclose(), which is correct — it prevents a concurrentgetSession()from handing out a session that is about to be destroyed. But ifclose()rejects, the error is logged (:409) and nothing else happens: the session is already out of every pool structure, so its underlying connection is no longer referenced, never retried, and never counted anywhere.That is not a leak in the common case — the RPC usually fails because the connection is already gone — but a transport-level failure would leave a real socket open with no owner. Keeping the session in a small "failed to close" set for a later retry, or at least counting it in a metric, would make the failure visible.
Not included
The
getSession()create-branch race that also came up in the #19 review is already fixed ondevelop(:266-276now locates the session by identity instead ofshift()ing the front of the idle queue), so there is nothing left to track there.I am happy to send a PR for any of these — please let me know which are worth changing and whether you would prefer them separately.