trails/apps
Ullrich Schäfer 8675c1f7c3
fix(journal): reuse a dedicated pool for /api/health instead of per-call connect
The previous handler opened a fresh postgres client (max: 1) on every
call to /api/health and tore it down in the finally block. Under the
prod monitoring cadence (probes every few seconds), that's a fresh
TCP + TLS + auth handshake on every probe, plus connection-table
churn on the Postgres side — fine for the trickle of curl-ish manual
checks, slow-bleed under blackbox monitoring.

Now we cache a module-level singleton postgres client dedicated to
/api/health (max: 2, idle_timeout: 30) and reuse it across calls.
Separate from the app's main DB pool (via @trails-cool/db's createDb)
on purpose — so a starvation event on the main pool doesn't fail the
liveness check and trigger a restart loop.

Full repo: pnpm typecheck, pnpm lint, pnpm test all green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 12:37:09 +02:00
..
journal fix(journal): reuse a dedicated pool for /api/health instead of per-call connect 2026-05-24 12:37:09 +02:00
mobile Bump the production group with 14 updates 2026-05-24 08:31:11 +00:00
planner fix(sentry): make DSN env-driven so self-hosters can opt out 2026-05-24 12:24:54 +02:00