PR #16786: fix(config): accept request_timeout_seconds / stale_timeout_seconds in providers entries (#16779)

• Repository: NousResearch/hermes-agent
• Author: briandevans
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/16786

Description (problem / solution / changelog)

Summary

• _normalize_custom_provider_entry()'s _KNOWN_KEYS set was missing request_timeout_seconds and stale_timeout_seconds, both of which are valid runtime keys and are documented in cli-config.yaml.example.
• Result: every CLI invocation that follows the documented example prints a spurious unknown config keys ignored: request_timeout_seconds, stale_timeout_seconds warning, even though hermes_cli/timeouts.py reads and applies both keys correctly.
• Fix: add the two keys to _KNOWN_KEYS. One-line addition, plus a regression test.

The bug

hermes_cli/config.py:2187-2191 (pre-fix):

_KNOWN_KEYS = {
    "name", "api", "url", "base_url", "api_key", "key_env",
    "api_mode", "transport", "model", "default_model", "models",
    "context_length", "rate_limit_delay",
}

But hermes_cli/timeouts.py reads:

• request_timeout_seconds at line 40 (get_provider_request_timeout).
• stale_timeout_seconds at lines 65 and 69 (get_provider_stale_timeout).

And cli-config.yaml.example documents both keys under the top-level providers: block (request_timeout_seconds: 300, stale_timeout_seconds: 900, etc.).

So users following the documented example see the validator complain about keys it actually accepts. That's not just noise: a "validator" warning telling users a key is "ignored" trains them to delete keys that are in fact load-bearing for their endpoint behavior.

The fix

Add both keys to the existing _KNOWN_KEYS set in _normalize_custom_provider_entry(). No other path needs changing — the runtime readers in timeouts.py already do the right thing.

Test plan

• Focused regression test: test_timeout_keys_not_warned in tests/hermes_cli/test_provider_config_validation.py — asserts a providers entry with both timeout keys produces zero "unknown config keys" warnings.
• Adjacent suite: full tests/hermes_cli/test_provider_config_validation.py — 17 passed (16 existing + 1 new).
• Regression guard: with only the test added (no _KNOWN_KEYS change), the test fails with AssertionError: ... got: ['providers.myhost: unknown config keys ignored: request_timeout_seconds, stale_timeout_seconds']. With the one-line fix applied, the test passes. So the test is genuinely guarding the runtime contract.

Related

• Fixes #16779.
• The runtime support for these keys landed in #12652 (request_timeout_seconds) and #12891 (stale_timeout_seconds); only the validator was out of sync.

Changed files

• hermes_cli/config.py (modified, +1/-0)
• tests/hermes_cli/test_provider_config_validation.py (modified, +23/-0)

PR #16812: fix(config): add request_timeout_seconds and stale_timeout_seconds to provider _KNOWN_KEYS (#16779)

• Repository: NousResearch/hermes-agent
• Author: vominh1919
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/16812

Description (problem / solution / changelog)

Summary

The provider-entry validator in hermes_cli/config.py has a _KNOWN_KEYS set that's out of sync with both the documented config example and the runtime code. It warns on request_timeout_seconds and stale_timeout_seconds as "unknown config keys ignored" even though those are:

1. Read at runtime — hermes_cli/timeouts.py:40 reads provider_config.get("request_timeout_seconds") and :69 reads provider_config.get("stale_timeout_seconds")
2. Documented — cli-config.yaml.example shows both keys in the providers: section

Fix

Add both keys to the _KNOWN_KEYS set (one-line change).

File changed: hermes_cli/config.py (+2 lines in set literal)

Impact

Eliminates false warnings for users who configure per-provider timeouts as documented. No behavioral change — the keys already work; this just stops the spurious warning.

Fixes #16779

Changed files

• hermes_cli/config.py (modified, +1/-0)