Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0
Labels: enhancement, backend, Stellar Wave, database
The pg pool is created with zero tuning, so under load it can exhaust connections and a slow query can hang forever.
backend/src/lib/prisma.ts:13 (and prisma/seed.ts:6) do new pg.Pool({ connectionString }) with no max, idleTimeoutMillis, connectionTimeoutMillis or statement_timeout. That leaves the node-postgres defaults in place: max 10 and no statement timeout. When traffic picks up the pool can run dry, and one slow query with no statement_timeout will hold a request handler open indefinitely.
What the fix has to hold to
- pool size and timeouts are env-configurable with sensible defaults
- a slow query can't hang a handler forever (statement_timeout applied)
- the new vars are documented
Done when
Where to start
backend/src/lib/prisma.ts and backend/prisma/seed.ts. Small change, mostly a config object plus env plumbing and the .env.example entries.
Labels:
enhancement,backend,Stellar Wave,databaseThe pg pool is created with zero tuning, so under load it can exhaust connections and a slow query can hang forever.
backend/src/lib/prisma.ts:13(andprisma/seed.ts:6) donew pg.Pool({ connectionString })with no max, idleTimeoutMillis, connectionTimeoutMillis or statement_timeout. That leaves the node-postgres defaults in place: max 10 and no statement timeout. When traffic picks up the pool can run dry, and one slow query with no statement_timeout will hold a request handler open indefinitely.What the fix has to hold to
Done when
backend/.env.exampleWhere to start
backend/src/lib/prisma.tsandbackend/prisma/seed.ts. Small change, mostly a config object plus env plumbing and the .env.example entries.