mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-31 19:16:29 +00:00
6b81590c55
Systematic prune per AGENTS.md test policy, one pass over every major test tree (gateway, hermes_cli, tools, agent, run_agent, plugins, cli, cron, tui_gateway, honcho/openviking, root-level): - DELETE: source-reading tests (read_text/getsource on prod files), change-detector tests (exact catalog counts, model-name snapshots, config version literals), mock-echo tests (assert a mock returns what it was told), assertion-free/trivial tests, near-duplicate parametrizations (boundaries + one representative kept), async/sync twin duplicates, cosmetic within-file variations. - KEEP (mandatory): security/redaction/approval guards, message-role alternation invariants, prompt-caching/deterministic-call-id invariants, issue-number regression tests (deduped), E2E tests. - 6 test files deleted outright (script-style/no-assert or fully redundant); conftest.py, fakes/, fixtures/ untouched. - tests/acp/conftest.py added: autouse fixture stubs the live models.dev/GitHub/Copilot/Anthropic inventory fetches that ACP server tests performed on every session create — test_server.py 147s → 3.4s, and the tests are now genuinely hermetic. - Sleep-based slowness shrunk where safe (codex_ttfb_watchdog, compression_concurrent_fork, etc.); no wall-clock assertion tightened. Verification: full hermetic suite via scripts/run_tests.sh — 2439 files, 31,130 tests passed, 0 failed, 0 flaky retries, 315s wall (baseline: 583s wall, 13,564s subprocess CPU).
40 lines
1.6 KiB
Python
40 lines
1.6 KiB
Python
"""Regression guard: a genuine Nous 429 must re-enter the retry loop so the
|
|
top-of-loop Nous rate-limit guard can activate the fallback chain.
|
|
|
|
Bug (found in the #44061 audit): the genuine-rate-limit branch in
|
|
``agent/conversation_loop.py`` set ``retry_count = max_retries`` then
|
|
``continue``-d, intending the top-of-loop guard to "handle fallback or bail
|
|
cleanly". But the loop condition is ``while retry_count < max_retries`` —
|
|
setting retry_count equal to max_retries makes the condition False
|
|
immediately, so the guard NEVER runs. No fallback activation, no clean
|
|
rate-limit message: the turn dies with the generic retry-exhaustion error.
|
|
|
|
The fix sets ``retry_count = max(0, max_retries - 1)`` so the loop body runs
|
|
exactly once more: the guard sees the breaker state recorded by
|
|
``record_nous_rate_limit()`` moments earlier and either activates a fallback
|
|
provider (resetting retry_count) or returns the explicit rate-limit failure.
|
|
"""
|
|
from __future__ import annotations
|
|
|
|
import inspect
|
|
import re
|
|
|
|
|
|
def _loop_reenters(retry_count: int, max_retries: int) -> bool:
|
|
"""Mirror of the ``while retry_count < max_retries`` loop condition."""
|
|
return retry_count < max_retries
|
|
|
|
|
|
class TestGenuineNous429ReentersLoop:
|
|
"""The assignment used by the genuine-429 branch must leave the loop
|
|
condition True so the top-of-loop guard gets a chance to run."""
|
|
|
|
def test_fixed_assignment_reenters_for_typical_max_retries(self):
|
|
for max_retries in (1, 2, 3, 5, 10):
|
|
retry_count = max(0, max_retries - 1)
|
|
assert _loop_reenters(retry_count, max_retries), (
|
|
f"max_retries={max_retries}: guard would never run"
|
|
)
|
|
|
|
|
|
|