Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

server/tests leaks database connections: 55 files open a pool and never close it

Aberta
  • Algo errado?
#785 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@adamsiwiec1 já está trabalhando nisso.

Desde 15/10/2026.

  • #796 de @adamsiwiec1 — aberto

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
70/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
postgresql, typescript
Domínio
testing

Direção de pesquisa

Start with server/tests: grep for files that open a database pool but never call $client.close(), and copy the afterAll pattern from identity-store.integration.test.ts, placing the close last. Then read the two sentences in scripts/test-server-sharded.ts that the issue quotes. Done when all 55 files close their pool, a guard test fails on a new file that opens a database without closing it, and the script's comments are corrected.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

What

55 test files in server/tests open a database pool and never give it back. bun test runs
every file in one process, so the pools accumulate for the whole run and main currently sits
at 98 files opening a database, 43 closing one.

PostgreSQL's ceiling is 100 (97, less the superuser reserve), and a file costs two
connections from its first query onward. main is close enough to that ceiling that the next
few integration tests added will cross it, and the failure lands on whoever adds them rather
than on anything they did wrong.

That already happened once: #770 added 19 such files, and its tests job reported 114
failures and 402 sorry, too many clients already — none of which were about the change
under review. It was fixed there by closing the 15 files that branch had added, which returns
the count to main's own, but main's 55 are untouched and the margin is unchanged.

Measured, because the prose in the tree says otherwise

scripts/test-server-sharded.ts states the slots are exhausted "during the import phase", and
concludes the ceiling is "a harness ceiling, not a regression, and it is never a reason to
change source". Both halves are worth revisiting — measurements from a Bun 1.4.2 / PostgreSQL
17 run:

Probe Result
Construct 5 pools, run no query 0 connections — construction opens nothing
Run one query on each 10 — a single query opens the pool's full max, not one
Leave 20 pools idle 20s flat at 40 — nothing is ever reaped
await db.$client.close() releases fully

So exhaustion is a function of how many files have run, not of how many have been imported.
A sharded sweep never sees it because each shard is a fresh process; test:ci walks straight
into it. That difference is why a branch can be green on every local gate and red on CI for a
reason that has nothing to do with it.

Proposed

  1. Close the remaining 55. await database.$client.close() as the last statement of the
    file's own afterAll, after that file's cleanup — the idiom 43 files already use (see
    identity-store.integration.test.ts). It must go last: Bun runs afterAll hooks
    first-registered-first, so a pool closed before the deletes takes the deletes with it.

  2. Enforce the pairing, so file 118 can't quietly reintroduce it. A guard test is the right
    tool rather than a lint rule: "a file that opens a database closes it" is a pairing rule, not
    an import restriction, and server/tests is outside tsc so types will not catch it either.

  3. Correct the two sentences in scripts/test-server-sharded.ts quoted above, and keep the
    runner — sharding is still worth having for wall-clock, just not as the only thing standing
    between the suite and the ceiling.

Considered and rejected
  • One shared pool for the suite. Bounds connections by construction (40 databases over one
    max: 4 pool measured 4, flat). But 43 files already close their own client, and the first
    one to do so kills a shared client for every file after it — measured, 466 failures, all
    PostgresError: Connection closed. It would mean removing teardown from 43 files and
    accepting that one stray close() anywhere detonates the run.
  • A helper that registers its own afterAll. Removes the convention entirely, and is the
    nicest design on paper. Bun runs hooks FIFO, so the helper's close (registered at import)
    always runs before the file's own cleanup — measured, 28 failures.
  • Raising max_connections in CI. GitHub Actions service containers can't override the
    container command, so it means running Postgres as an explicit step. It also masks the leak
    and leaves bun test server/tests broken locally.

Not included

While fixing this on #770 we found an unrelated latent bug of the same family: a test read the
audit trail with no ORDER BY and asserted .at(-1) was the most recent row. It passed locally
and failed on CI, reporting an audit misattribution the product had not committed. Fixed in
#770 (arcade-journey); the suite's other 37 audit reads use set semantics and are not at risk.
Worth a look if positional access on unordered reads shows up elsewhere.

Linguagem predominante
TypeScript
Estrelas
6.6k
Forks
914
Merge médio
23h 27min
PRs com merge (30d)
136

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de CopilotKit/OpenBot

Todas as issues de CopilotKit/OpenBot

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.