mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-24 16:54:43 +00:00
089f09fa5f
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
1 line
13 B
Text
1 line
13 B
Text
cifangyiquan
|