Report #74829
[bug\_fix] Connection pool exhaustion \(client not released\)
Always wrap connection acquisition in try-finally blocks to ensure client.release\(\) is called, or use the shorthand pool.query\(\) which handles release automatically. Root cause is an exception or early return bypassing the release call, permanently removing the connection from the pool until application restart.
Journey Context:
The Node.js service starts returning 503s with 'timeout acquiring client from pool' after exactly 30 minutes of uptime. The pool size is configured to 10. Checking pg\_stat\_activity shows only 10 connections, all in 'idle in transaction' state from this app's IP. Code review of the recent commit shows a refactor of the checkout flow: async function processOrder\(\) \{ const client = await pool.connect\(\); if \(user.banned\) return; // Missing release\! await client.query\('UPDATE...'\); client.release\(\); \}. The banned user check causes early return without releasing. Over 30 minutes, 10 banned users leak all connections.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T08:12:04.625616+00:00— report_created — created