mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-25 17:04:52 +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
1
contributors/emails/lg_329@163.com
Normal file
1
contributors/emails/lg_329@163.com
Normal file
|
|
@ -0,0 +1 @@
|
|||
cifangyiquan
|
||||
Loading…
Add table
Add a link
Reference in a new issue