hermes-agent

mirrors/hermes-agent

Fork 0

mirror of https://github.com/NousResearch/hermes-agent.git synced 2026-07-31 19:16:29 +00:00

Commit graph

Author	SHA1	Message	Date
Teknium	6b81590c55	test: prune low-value tests suite-wide (wave 1) — 46,820 → 28,106 test functions 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).	2026-07-29 13:10:23 -07:00
Teknium	d93c905808	fix: /browser connect times out when another app squats the CDP port On Windows (and some Linux setups), an application like VS Code's js-debug can hold 127.0.0.1:9222 while a Chromium browser launched with --remote-debugging-port=9222 silently binds [::1]:9222 only. The IPv4-only probe then (a) missed the live browser entirely and (b) hung against the squatter — which accepts TCP but never answers the /json/version HTTP probe — repeatedly, driving the whole connect past the desktop GUI's RPC deadline: 'error: request timed out: browser.manage'. Fix, applied to both the gateway browser.manage RPC and the CLI /browser connect path via shared helpers in browser_connect.py: - discover_local_cdp_url(): probe BOTH loopbacks (127.0.0.1 first, then [::1]) and adopt whichever actually speaks CDP. - local_port_in_use() + find_free_debug_port(): when neither loopback speaks CDP but the port is held by another application, report the squatter explicitly and launch the debug browser on a nearby free port instead of fighting a bind conflict on 9222. - Bound the gateway's post-launch wait to a 10s deadline (was up to 20 unbounded probe cycles) so connect always answers inside the client RPC timeout. - _wait_for_browser_debug_ready_or_exit() also probes dual-stack so a successful launch pushed onto [::1] is classified 'ready'. Verified on a live Windows repro (VS Code holding 127.0.0.1:9222, Chrome 148 on [::1]:9222): connect now resolves http://[::1]:9222 in ~4.5s instead of timing out.	2026-07-18 02:49:28 -07:00

Author

SHA1

Message

Date

Teknium

6b81590c55

test: prune low-value tests suite-wide (wave 1) — 46,820 → 28,106 test functions

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).

2026-07-29 13:10:23 -07:00

Teknium

d93c905808

fix: /browser connect times out when another app squats the CDP port

On Windows (and some Linux setups), an application like VS Code's
js-debug can hold 127.0.0.1:9222 while a Chromium browser launched
with --remote-debugging-port=9222 silently binds [::1]:9222 only.
The IPv4-only probe then (a) missed the live browser entirely and
(b) hung against the squatter — which accepts TCP but never answers
the /json/version HTTP probe — repeatedly, driving the whole connect
past the desktop GUI's RPC deadline:
'error: request timed out: browser.manage'.

Fix, applied to both the gateway browser.manage RPC and the CLI
/browser connect path via shared helpers in browser_connect.py:

- discover_local_cdp_url(): probe BOTH loopbacks (127.0.0.1 first,
  then [::1]) and adopt whichever actually speaks CDP.
- local_port_in_use() + find_free_debug_port(): when neither loopback
  speaks CDP but the port is held by another application, report the
  squatter explicitly and launch the debug browser on a nearby free
  port instead of fighting a bind conflict on 9222.
- Bound the gateway's post-launch wait to a 10s deadline (was up to
  20 unbounded probe cycles) so connect always answers inside the
  client RPC timeout.
- _wait_for_browser_debug_ready_or_exit() also probes dual-stack so a
  successful launch pushed onto [::1] is classified 'ready'.

Verified on a live Windows repro (VS Code holding 127.0.0.1:9222,
Chrome 148 on [::1]:9222): connect now resolves http://[::1]:9222
in ~4.5s instead of timing out.

2026-07-18 02:49:28 -07:00

2 commits