mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-24 16:54:43 +00:00
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 in683059feb5), so the original diff no longer applies. Their production diagnosis and non-retryable direction preserved. Refs: #38803, #37011
This commit is contained in:
parent
9e4b89857a
commit
089f09fa5f
3 changed files with 94 additions and 0 deletions
|
|
@ -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:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue