fix(api_server): mark rejected API_SERVER_KEY as non-retryable fatal error

When _api_key_passes_startup_guard() rejects the key (missing,
placeholder/too short, or fail-closed unverifiable strength), connect()
returned a bare False with no fatal-error info. gateway.run's reconnect
watcher treats that as transient and re-queues with backoff forever —
each retry re-instantiating the adapter and its ResponseStore sqlite
connection. Observed in production (#37011): ~501 leaked connections
(1002 fds) over ~2.5 days until EMFILE made the whole gateway
unresponsive.

Set a non-retryable fatal error (api_server_key_invalid) in connect()
when the guard rejects, covering all three rejection branches, so the
platform drops from the reconnect queue; recover with
`/platform resume api_server` after fixing the key. Same treatment as
the port-conflict guard (api_server_port_in_use, #65665 / bda8bd76a8).

Tests mirror the port-conflict precedent: each rejection path asserts
connect() is False, has_fatal_error True, fatal_error_retryable False,
and fatal_error_code api_server_key_invalid, plus a strong-key control.

Re-implementation of #38803 by @cifangyiquan against current main —
their patch targeted the old inline guard in connect() which was since
extracted to _api_key_passes_startup_guard() (and gained the
fail-closed branch in 683059feb5), so the original diff no longer
applies. Their production diagnosis and non-retryable direction
preserved.

Refs: #38803, #37011
This commit is contained in:
cifangyiquan 2026-07-23 08:25:25 -07:00 committed by Teknium
parent 9e4b89857a
commit 089f09fa5f
3 changed files with 94 additions and 0 deletions

View file

@ -5526,6 +5526,26 @@ class APIServerAdapter(BasePlatformAdapter):
return False
if not self._api_key_passes_startup_guard():
# A rejected API_SERVER_KEY is a configuration error, not a
# transient blip — the key will not become valid on its own. A
# bare ``return False`` makes the reconnect watcher in
# gateway.run treat it as retryable and loop forever at the
# backoff cap, re-instantiating the adapter (and its
# ResponseStore sqlite connection) every retry (#38803: ~501
# leaked connections / 1002 fds over 2.5 days until EMFILE took
# the whole gateway down). Non-retryable drops it from the
# reconnect queue — same treatment as the port-conflict guard
# (api_server_port_in_use). The guard already logged the
# specific rejection reason just above.
self._set_fatal_error(
"api_server_key_invalid",
"API_SERVER_KEY was rejected by the startup guard (missing, "
"placeholder/too short, or strength unverifiable — see the "
"error logged above). Generate a strong secret (e.g. "
"`openssl rand -hex 32`), set API_SERVER_KEY, then "
"`/platform resume api_server`.",
retryable=False,
)
return False
try: