Skip to content

Hermes plugin: search survives slow servers, no false version warning, faster install and lookups (CON-04, HER-09/10/12) - #56

Merged
Pavel-Tk merged 1 commit into
mainfrom
fix/hermes-timeouts-p2
Oct 12, 2026
Merged

Pavel-Tk merged 1 commit into
mainfrom
fix/hermes-timeouts-p2

Conversation

@Pavel-Tk

Copy link
Copy Markdown
Contributor

Hermes plugin fixes from the 2026-10-11 customer test. Version 0.9.1 (CHANGELOG entry added).

CON-04: search survives slow servers (P1)

  • memory_search, memory_expand, memory_evidence: 15 s total budget (SUBSTRATE_TOOL_TIMEOUT_SECONDS, clamped 3-60 s). First attempt 7 s; one retry with the remaining budget, only for timeout, transport_error, server_error, internal. No retry for 4xx-class answers.
  • When the retry is spent the tool returns {"error":"timeout","message":"Substrate memory is busy or slow right now. Try again in a moment. ..."}, so the agent does not say it lacks access to a source.
  • Per-turn recall TURN_CONTEXT_TIMEOUT 2.0 -> 2.5 s, so it stays above the server's 1500 ms deadline with about 1 s of headroom.
  • Tested: retry on timeout, busy message after two timeouts (parametrised over timeout/transport/5xx), no retry on 400/404/429/413, budget env override and clamping, evidence uses the same budget, turn-context budget.

HER-10: no false version warning

  • host_version_notice: 0.0.0, vgit.*, dev, empty are unknown and get no note.
  • The note is no longer added to pre_llm_call (it was repeated on answers; the process flag did not survive a host that reloads the plugin per message). It is added once to the connect announcement.
  • Tested: unknown builds silent; an old host (0.20.3) gets the note once in the connect announcement and never on ordinary turns.

HER-09: install picked up dependency tooling (P2), partly fixed

  • Cause: the repository root had pyproject.toml (dev tooling with [project] and [dev] extras) plus uv.lock. Hermes treats a root pyproject.toml as a plugin dependency project (see CHANGELOG 0.8.1). plugin.yaml already said python_runtime: external, which the owner's Hermes evidently does not stop.
  • Change: pyproject.toml and uv.lock move to tooling/ (lock content unchanged). pytest config moves to root pytest.ini, ruff config to root ruff.toml. CI, release workflows, README, CONTRIBUTING, docs/releasing and dependabot now use uv sync --project tooling --frozen --extra dev with UV_PROJECT_ENVIRONMENT=$PWD/.venv.
  • Tested: the tooling venv syncs from tooling/uv.lock with --frozen; full suite on 3.11 and 3.12; test_packaging asserts there is no root pyproject.toml.
  • Not verified: the owner's newer Hermes installer source is not on this machine (the checkout at plugin_compare is 0.21.0 and does no plugin dependency install), so I could not reproduce the 2 min 47 s install. The fix removes the file that triggers it per the 0.8.1 notes. Re-test with hermes plugins install <repo URL> on a Hermes build that shows the problem.

HER-12: lookups take 10-28 s (P2), not fixable from the plugin

  • Hermes (checkout at ~/plugin_compare/hermes-agent, tools/tool_search.py) defers every non-core plugin tool behind the tool_search / tool_describe / tool_call bridge when tools.tool_search.enabled is auto (default) or on. _HERMES_CORE_TOOLS is Hermes-owned and register_tool has no always-load option. The only direct surfaces are the desktop_ui and project toolsets, which are not for this.
  • Plugin-side: the memory_search description is now short and direct (see follow-ups).
  • Workaround for users, documented in the plugin README and not applied automatically: tools.tool_search.enabled: off.
  • Needs a Hermes-side change: an always-load flag for plugin tools.

Follow-ups from substrate-v5 PR #83

  • memory_search description: the server's tools/list description (which names the connected sources) is used when present. Fetched once per process in a background thread, cached; fallback text kept when missing, non-string, empty, over 1000 chars or failing. Failures are retried after 5 minutes.
  • payload_too_large added to _PERMANENT_TOOL_ERRORS (tool errors), so oversized captures are split or quarantined, not retried.
  • Rejected import/capture items: logged at WARNING on substrate.spool with kind, event_id and the server's error plus hint (bounded, control characters stripped). Logged in both the batch and single-item paths.

Tests

  • .venv built exactly as CI does (uv sync --project tooling --frozen --extra dev), Python 3.11 and 3.12: full suite 426 passed, 5 skipped each (server and host checkouts absent). ruff check ., compileall, check_public_hygiene.py, JSON validation, build_release.py and --check all pass.
  • New tests in tests/test_substrate_plugin.py (+ fake-server hooks in tests/conftest.py) and tests/test_packaging.py.
  • Test fix: test_tool_404_carries_permanent_signal asserted fake_mcp.hits == 1, which was racy (the spool sender can post memory_import in the same window) and counted the initialize POST. The hit count is removed; permanence is still asserted via the quarantine counter and transient is False.
  • Autouse conftest fixture keeps the background description fetch out of the suite.

Version

VERSION, root and plugin plugin.yaml, client.PLUGIN_VERSION, release workflow version check, packaging tests, README/COMPATIBILITY current-release rows: 0.9.0 -> 0.9.1.

🤖 Generated with Claude Code

…, faster install and lookups (CON-04, HER-09/10/12)

CON-04: memory_search, memory_expand and memory_evidence are user-invoked,
so they get a 15 s budget (SUBSTRATE_TOOL_TIMEOUT_SECONDS, 3-60 s) with one
retry for timeout, connection reset and 5xx; 4xx is never retried. When the
retry is spent the tool says "Substrate memory is busy or slow right now".
Per-turn recall moves to 2.5 s so it stays above the server's 1500 ms
deadline with headroom.

HER-10: an unknown or 0.0.0 Hermes build gets no version note. An older
Hermes gets its one note at connect time, never on ordinary answers.

HER-09: the repository root carried a pyproject.toml, which Hermes treats
as a plugin dependency project on install. The dev tooling project and its
uv.lock move to tooling/ (CI uses uv sync --project tooling); pytest and
ruff settings move to root pytest.ini and ruff.toml.

HER-12: not fixable from the plugin. Hermes defers non-core plugin tools
behind tool search; see the README note on tools.tool_search.

Follow-ups: memory_search uses the server's tools/list description when
present (fetched once per process, cached, fallback text kept);
payload_too_large is a permanent tool error; rejected import items are
logged with the server's error and hint.

Version 0.9.1.

Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJwSpwAivFKrfusNkeh96b
Signed-off-by: Pavel-Tk <110731619+Pavel-Tk@users.noreply.github.com>
@Pavel-Tk
Pavel-Tk merged commit 4ac6714 into main Oct 12, 2026
5 checks passed
@Pavel-Tk
Pavel-Tk deleted the fix/hermes-timeouts-p2 branch October 12, 2026 22:45
Pavel-Tk added a commit that referenced this pull request Oct 13, 2026
test_repository_root_is_not_a_python_project_for_hermes (from #56) asserted
"ruff==0.9.10" and "pytest==9.0.3", so every Dependabot bump in tooling/
failed CI (#61, #62). It now checks that ruff and pytest are pinned to some
version.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJwSpwAivFKrfusNkeh96b
Signed-off-by: Pavel-Tk <110731619+Pavel-Tk@users.noreply.github.com>
Pavel-Tk added a commit that referenced this pull request Oct 13, 2026
test_repository_root_is_not_a_python_project_for_hermes (from #56) asserted
"ruff==0.9.10" and "pytest==9.0.3", so every Dependabot bump in tooling/
failed CI (#61, #62). It now checks that ruff and pytest are pinned to some
version.


Claude-Session: https://claude.ai/code/session_01PJwSpwAivFKrfusNkeh96b

Signed-off-by: Pavel-Tk <110731619+Pavel-Tk@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant