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

Fermée
  • Quelque chose ne va pas ?
#788 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@anth-volk y travaille déjà.

Depuis le 13/10/2026.

  • #789 par @anth-volk — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
python, sqlalchemy
Domaine
backend, databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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.
Langage dominant
Python
Étoiles
1
Forks
1
Merge moyen
1 j 17 h
PR mergées (30 j)
76

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de PolicyEngine/policyengine-sim-api

Toutes les issues de PolicyEngine/policyengine-sim-api

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.