[pdp2121]

High Level Overview of Change

Stops vhs-connections crash-looping when the Knex pool saturates.

• Install an unhandledRejection handler in all three services (connection-manager, crawler, api) so a failed database call is logged instead of exiting the process
• saveValidator: catch the second statement, which had no error handler
• Catch the five fire-and-forget call sites in wsHandling.ts and agreement.ts
• Bound the Knex pool explicitly (min: 2, max: 20) — the knex default of 10 was the ceiling
• Drop acquireConnectionTimeout from 120s to 30s so a backlog surfaces instead of queueing

Context of Change

• vhs-connections was restarting 90–144 times per 24h across dev, staging and prod, with reason=Error (not OOMKilled)
• saveValidator's second statement had no .catch():

  await query('validators')
    .where({ signing_key: validator.signing_key, revoked: null })
    .update({ revoked: false })      // no handler

• Its caller is fire-and-forget — void agreement.handleValidation(...) — so a KnexTimeoutError propagated out as an unhandled rejection. Since Node 15 that throws, which exits the process
• A scan found the same shape at 7 more void sites and 6 unguarded timer callbacks, all calling functions with no internal try/catch. Patching each individually would leave the next unfound path to crash the same way, so the global handler is the actual fix and the targeted .catch() calls just keep errors attributable in logs
• The exhausted pool is Knex's client-side pool, not Postgres. RDS was at 23 of 838 connections, so raising max uses headroom that already exists
• uncaughtException is deliberately not trapped — a synchronous throw can leave the process in an indeterminate state where continuing is worse than restarting

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates
• Release

Before / After

• Before: one transient KnexTimeoutError → unhandled rejection → process exit → k8s restart → repeat
• After: the error is logged, the service stays up, and the next validation or job run retries
• Verified directly: an unhandled rejection exits with code 1 without the guard; with it, the rejection is logged and the process continues and exits 0
• Pool ceiling raised from 10 to 20; a saturated pool now fails in 30s rather than queueing for 2 minutes