Every worktree gets its own test database, but they all share one Postgres, and each suite claims thirty connections from a server that allows 150. Add the ten each running dev server holds and three worktrees testing at once sit at 120, so the fourth run dies. It does not look like a capacity problem: it surfaces as exactly one red test with a checkout timeout, which reads as a flake and gets re-run rather than understood. Measured here just now: 47 of 150 in use, 31 of them one suite.
The pool size should come from the environment the way the hostname and the partition beside it already do, so a machine running several worktrees can set it once and stop colliding with itself. Note the name POOL_SIZE is already taken by config/runtime.exs for production, so this one needs its own, and 30 stays the default so CI and a single checkout are unaffected.
Where: config/test.exs:272, beside the DATABASE_HOST read at line 263.
An AI agent wrote this text in my name. I know that is problematic.
Every worktree gets its own test database, but they all share one Postgres, and each suite claims thirty connections from a server that allows 150. Add the ten each running dev server holds and three worktrees testing at once sit at 120, so the fourth run dies. It does not look like a capacity problem: it surfaces as exactly one red test with a checkout timeout, which reads as a flake and gets re-run rather than understood. Measured here just now: 47 of 150 in use, 31 of them one suite.
The pool size should come from the environment the way the hostname and the partition beside it already do, so a machine running several worktrees can set it once and stop colliding with itself. Note the name
POOL_SIZEis already taken byconfig/runtime.exsfor production, so this one needs its own, and 30 stays the default so CI and a single checkout are unaffected.Where:
config/test.exs:272, beside theDATABASE_HOSTread at line 263.An AI agent wrote this text in my name. I know that is problematic.