| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
A pool whose connections all fail to create reports only the generic
"Pool '<name>' is empty (size N, active 0, idle 0)" message, swallowing
the underlying connect failure (for example a TLS or timeout error from
the backend). Consumers that log only the exception message — like the
Appwrite dedicated-database bootstrap retry loop — are left with no way
to see why the pool never filled.
Remember the last connection-creation failure and append its message to
both exhaustion messages ("is empty" and "failed to provide a
connection"), and chain the original exception through the
createConnection wrapper so the full cause survives via getPrevious().
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Greptile SummaryThis PR surfaces the underlying connection failure inside pool-exhaustion exception messages so consumers that only log getMessage() can see why the pool never filled, without requiring callers to inspect the previous chain.
Confidence Score: 5/5Safe to merge — the change is narrowly scoped to error message formatting and exception chaining, with no impact on connection lifecycle or pool state. Both code paths (connection failure and plain exhaustion) are exercised by the new tests, which also validate the full getPrevious() depth. The lastError() helper is stateless and only called at throw sites, so it cannot affect normal operation. The only pre-existing unreachable fallback in createConnection() is untouched and harmless. No files require special attention. Important Files Changed
Reviews (1): Last reviewed commit: "fix: surface last connection error in po..." | Re-trigger Greptile |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What
When every connection attempt fails, Pool::pop() throws the generic Pool '<name>' is empty (size N, active 0, idle 0) message. The underlying connect failure is chained as previous but never shown, so consumers that log only the exception message have no way to see why the pool never filled.
Seen live during DAT-1556 (appwrite-labs/cloud): a dedicated-database schema bootstrap retried for minutes against Pool 'db-{hash}.fra.appwrite.center' is empty (size 10, active 0, idle 0) while the actual cause — libpq's TLS negotiation hanging against the databases front — was invisible.
Changes
Tests
Pairs with the appwrite-labs/cloud PR for DAT-1556 (cloud picks this up via a patch release once merged).
🤖 Generated with Claude Code