Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#788 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@anth-volk 已经在做这个了。

开始于 2026年10月13日。

  • #789 来自 @anth-volk —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
停滞
技术栈
python, sqlalchemy
领域
backend, databases

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.
主要语言
Python
星标
1
派生
1
平均合并
1 天 8 小时
30 天内合并 PR
51

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

PolicyEngine/policyengine-sim-api 的其他 Issue

查看 PolicyEngine/policyengine-sim-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。