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

Stage 12 runs exhaust the database session pooler's 15-client limit

Closed
  • Is something wrong?
#788 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@anth-volk is already working on this.

Since Oct 13, 2026.

  • #789 by @anth-volk — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
python, sqlalchemy
Domain
backend, databases

Research direction

Start at create_stage12_engine, which sets SQLAlchemy's QueuePool with pool_size=5 and max_overflow=5, and at runtime_store(), which builds a new engine per coordinator and worker call. Pull request #789 is already open against this work, so read it and its diff before starting anything. Done means a connection is held only for each short operation, refused connections are retried with bounded backoff, and a failed failure-record write no longer replaces the original error.

Written by the indexing model from the issue text.

Description

Problem

Stage 12 coordinators and workers run out of database sessions. From 6 to 13 October 2026, 106 of the 153 production Stage 12 failures recorded:

FATAL: (EMAXCONNSESSION) max clients reached in session mode - max clients are limited to pool_size: 15

These were 100 US nationwide, 5 UK nationwide and 1 US state report. In 66 of them the coordinator failed at its initial claim, before any simulation started.

When the database is full, the failure handler's own write can also fail. The original error is then lost, and the comparison or simulation record stays running.

Cause

  • create_stage12_engine used SQLAlchemy's default QueuePool with pool_size=5 and max_overflow=5.
  • runtime_store() builds a new engine for every coordinator and worker invocation.
  • A connection returned to QueuePool keeps its physical session open. Each process therefore holds a pooler session while it calculates or waits, for up to 50 minutes.
  • pool_recycle=300 doesn't help, because recycling is only checked when a connection is checked out.
  • The coordinator and both country workers each allow 10 containers. Up to 30 processes can therefore each hold a session against a limit of 15.

Expected

  • A database session is held only for each short operation.
  • A connection refused before any statement is sent is retried, with a bounded backoff.
  • A failure to write the failure record never replaces the original error.

Follow-ups (not in scope)

  • Mark comparison and simulation rows that stay running past the coordinator's 4,500 s timeout as failed. This needs a scheduled function. It would read STAGE12_DATABASE_URL, which comes from Google Secret Manager and reaches Modal through the stage12-evaluation-runtime secret. No workflow currently runs .github/scripts/stage12-sync-modal-secrets.sh, so how that Modal secret is populated is unconfirmed.
  • Consider the transaction-mode pooler if concurrent database operations still approach 15 after this change.
Dominant language
Python
Stars
1
Forks
1
Avg merge
1d 7h
Merged PRs (30d)
40

Getting set up

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 PolicyEngine/policyengine-sim-api

All issues in PolicyEngine/policyengine-sim-api

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.