Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#788 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@anth-volk đang làm issue này rồi.

Từ ngày 13/10/2026.

  • #789 của @anth-volk — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
python, sqlalchemy
Lĩnh vực
backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Python
Star
1
Fork
1
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
51

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của PolicyEngine/policyengine-sim-api

Tất cả issue của PolicyEngine/policyengine-sim-api

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.