KnexTimeoutError from the connection pool: distinguishing a real leak from undersized pool settings

When Knex cannot hand out a pooled connection within the configured acquire timeout, queries reject with a pool acquisition error (commonly surfaced as a KnexTimeoutError) rather than a database error. The component in question is the connection pool layer between Knex query execution and the driver.

Two failure modes appear to produce the same symptom: connections checked out and never released (for example a transaction where the trx object is not threaded through every query, or a commit/rollback path that never runs), versus a pool whose min/max, acquireTimeoutMillis, and idleTimeoutMillis are simply too small for burst load. The diagnostic distinction matters because lowering timeouts can expose leaks faster but also increases transient rejections under legitimate concurrency.

A related uncertainty is short-lived processes: without knex.destroy() in teardown, pools and sockets can stay alive and mimic a leak in tests or serverless runs.

• What pool state or metrics (pending acquires versus in-use connections) reliably separate a missing-release bug from an undersized pool?
• Is there a documented way to log or inspect acquire/release events per query to find which code path holds the connection?
• Does the answer differ across drivers (pg, mysql2, sqlite3) or Knex/tarn versions, and which version assumptions should be stated?