Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

pg pool is unconfigured and saturating at the default max of 10

Open Beginner friendly
  • Is something wrong?
#411 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
postgresql, typescript
Domain
backend, databases

Research direction

The pool is constructed in server/src/util/db.ts, where the new Pool({...}) call passes only connection details. Read the pg Pool options and the sslConfig() helper there, then set max, connectionTimeoutMillis and idleTimeoutMillis explicitly, with comments explaining the chosen numbers. Done when the options are explicit in that file and the choice of max is justified against the instance's max_connections; the Bot.setName change is optional and separate.

Written by the indexing model from the issue text.

Description

priority: medium tech-debt

Noticed on 2026-10-10 during the RDS memory investigation.

The pool has no settings

server/src/util/db.ts builds the production pool with connection details only:

return new Pool({
  user: process.env.RDS_USERNAME,
  host: process.env.RDS_HOSTNAME,
  database: process.env.RDS_DB_NAME,
  password: process.env.RDS_PASSWORD,
  port: parseInt(process.env.RDS_PORT || '5432'),
  ssl: sslConfig(),
});

No max, no idleTimeoutMillis, no connectionTimeoutMillis — so it inherits pg's defaults (max: 10, 10s idle, no connect timeout).

It is actually hitting the ceiling

RDS DatabaseConnections over 7 days to 2026-10-10 sat at a maximum of exactly 10–11 in every 6-hour bucket, continuously — i.e. the pool pegs its limit as a matter of routine, not under load spikes. The average stepped from 3.3 to 5.7 on 2026-10-08 when ladder throughput rose, with no app restart.

Two consequences:

  • No connect timeout. A request that arrives with all 10 checked out waits indefinitely for a free client rather than failing fast. Under sustained background load that is a request hanging, not a 503 — harder to see and harder to alarm on.
  • The ladder competes with users for the same 10. Nothing reserves headroom for interactive traffic, so background matchmaking can starve a page load. #406's saturation cap should remove most of that pressure, but the structural issue stands.

The instance can take far more than 10: a db.t3.micro computes max_connections as LEAST(DBInstanceClassMemory/9531392, 5000) ≈ 112. The limit is ours, not the database's.

Suggested fix

Set the pool options explicitly, with comments explaining the numbers — the point is that they become a deliberate choice rather than a pg default nobody picked:

  • max — sized against the instance's max_connections with room for other consumers, not left implicit
  • connectionTimeoutMillis — so pool exhaustion surfaces as an error (and a db.error log + alarm) rather than an indefinite wait
  • idleTimeoutMillis — explicit rather than inherited

Related, smaller

Bot.setName calls appService.get(appId) on every script load to compare the name before writing — once per bot, so 10 full-row SELECTs per ladder match, each pulling the source column. The write is correctly guarded (it only UPDATEs when the name differs), so this is read load on a small, fully-cached table rather than a real problem — but the fetch is avoidable if the name were available in memory on the Process/Bot. Worth folding in only if this file is being touched anyway.

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
21h 23m
Merged PRs (30d)
9

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.