Repository navigation
fix(cli,db): DATABASE_POOL_MAX caps every served role - #818
Conversation
A served role boots through startDb, which installs its own postgresClient, so defaultClient() (the only reader of DATABASE_POOL_MAX) never ran and every role pooled at its POOL_PROFILES default (web 20, sync 10, worker 8). A fleet sized to fit its role's CONNECTION LIMIT was refused 53300 "too many connections for role" mid-roll (seen on tesote/marketing). startDb now layers DATABASE_POOL_MAX from the boot's env over the role default for the primary and the standby; poolMaxFromEnv(env) is exported. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
✅ Reviewed — nothing blocking0 actionable comment(s) · grounded on your code ⏱ 2m 08s wall clock · 🤖 developerz.ai — automated review, running on your model and your box. |
![developerz-ai[bot]](https://avatars.githubusercontent.com/in/3783704?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review summary — 6 file(s), 0 finding(s).
Completed review [bot]: boot now applies DATABASE_POOL_MAX from the supplied environment to primary and standby pools, preserving role defaults when unset. No concrete defects found in the supplied diff.
No findings from: concern-security, concern-tests.
🤖 developerz.ai review — automated, running on your model and your box. What is this?
Reviewed by router/gpt-6.1-sol on box hv-dedicated-5 — 97.7k in / 352 out over 3 calls; cost unknown: no price on record for router/gpt-6.1-sol.
What
startDb(packages/cli/src/runtime-queue.ts) now builds the primary, and the standby viaattachReplica, withprofile: poolMaxFromEnv(env), read from the env the boot was handed.poolMaxFromEnvtakes an optional env and is exported from@ultimat3/db.Why
Every served role installs its own client in
startDb, sodefaultClient()never runs, and it was the only code that readDATABASE_POOL_MAX. Every role therefore ran itsPOOL_PROFILESdefault whatever the operator set.Seen in prod on tesote/marketing (Ultimate 27.13.1): the stack sets web 4, sync 2, worker 6, scheduler 2 against
CONNECTION LIMIT 60. The pods actually ran 20/10/8/2, which is about 142 connections mid-roll. Sync and scheduler pods crashed withX_DB_POOL_EXHAUSTED … [SQLSTATE 53300] too many connections for roleonselect 1at boot, two restarts per rollout.Test
runtime-queue.test.ts(unit, no database):DATABASE_POOL_MAX=4in the boot env caps the primary and the standby at 4. Without the fix it fails withExpected: 4, Received: 20. An unset value keeps the role default.Typecheck green; 20 tests across runtime-queue, runtime-replica and pool-profile pass; biome clean. CHANGELOG
[Unreleased]entry added.🤖 Generated with Claude Code