fix(db): survive a database restart and a not-yet-ready database
CI / lint (push) Successful in 4s
CI / unit (push) Successful in 50s
CI / integration (push) Successful in 2m21s
CI / publish (push) Successful in 1m2s

Two connection-recovery gaps, both surfaced by a Postgres restart that left
the app throwing tracebacks while the DB itself was healthy.

pool_pre_ping + pool_recycle on the app engine [#2626]: when the database
restarts, every connection already in the pool is dead at the socket level.
SQLAlchemy only discovered that by failing a real query, so the first
operation after a restart errored out on whatever triggered it. pre_ping
checks liveness on checkout and swaps the dead connection transparently;
pool_recycle caps connection age so a socket stranded by a NAT/conntrack
timeout or a Docker network rebuild is retired on a timer instead.

wait_for_database() gate at startup [#2627]: create_app touches the DB
synchronously (migrations, secret re-encryption, settings load) and assumed
it was both resolvable and accepting connections on the first try. Neither
holds after a host reboot (Docker DNS not yet serving `db` -> gaierror -2)
or an unclean shutdown (Postgres still replaying WAL -> "not yet accepting
connections"). Both are transient, so retry with capped backoff behind one
gate ahead of the first DB touch. Credential and missing-database errors
are classified by SQLSTATE and still fail immediately -- waiting cannot fix
those. Budget is bootstrap-configurable (STEWARD_DB_CONNECT_TIMEOUT /
database.connect_timeout, default 60s) since it governs reaching the DB and
so cannot live in the DB-backed settings.

Tests drive the retry loop off a fake clock, so backoff and timeout
behaviour are deterministic rather than wall-clock dependent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-12 23:21:58 -04:00
co-authored by Claude Opus 5
parent 4b97bd01ea
commit 6c9b89390a
6 changed files with 464 additions and 2 deletions
+37
View File
@@ -49,6 +49,8 @@ def load_bootstrap(config_path: Path | str | None = None) -> dict[str, Any]:
secret_key = _resolve_secret_key(raw)
db_connect_timeout = _resolve_db_connect_timeout(raw)
# Plugin discovery spans two roots (see load_plugins / migration_runner):
# • bundled — first-party plugins shipped inside the image at repo-root
# `plugins/`; they version atomically with core and are read-only at runtime.
@@ -68,12 +70,47 @@ def load_bootstrap(config_path: Path | str | None = None) -> dict[str, Any]:
return {
"database_url": database_url,
"secret_key": secret_key,
"db_connect_timeout": db_connect_timeout,
"plugin_dirs": plugin_dirs,
# Installs/downloads target the external (writable, persistent) dir.
"plugin_install_dir": external_plugin_dir or bundled_plugin_dir,
}
def _resolve_db_connect_timeout(raw: dict) -> float:
"""How long to wait for the database at startup, in seconds.
Bootstrap-only by necessity: this governs reaching the DB, so it cannot
itself be read from the DB like the rest of Steward's settings.
A deployment whose database is slower to come up than the default (a large
cluster replaying WAL, a remote DB behind a link that takes a while) can
raise it rather than crash-looping the container.
"""
from .database import DB_CONNECT_TIMEOUT_SECONDS
value = _env("DB_CONNECT_TIMEOUT") or raw.get("database", {}).get("connect_timeout")
if value is None or value == "":
return DB_CONNECT_TIMEOUT_SECONDS
try:
parsed = float(value)
except (TypeError, ValueError):
logger.warning(
"Invalid database connect timeout %r — using default %.0fs",
value, DB_CONNECT_TIMEOUT_SECONDS,
)
return DB_CONNECT_TIMEOUT_SECONDS
if parsed <= 0:
# 0/negative would mean "never wait", which is the broken behaviour this
# setting exists to fix — treat it as a mistake, not as an opt-out.
logger.warning(
"Database connect timeout %.0fs is not positive — using default %.0fs",
parsed, DB_CONNECT_TIMEOUT_SECONDS,
)
return DB_CONNECT_TIMEOUT_SECONDS
return parsed
def _resolve_secret_key(raw: dict) -> str:
"""Resolve secret_key: env var → file → auto-generate.