fix(dashboard): guard update endpoint in Docker with structured guidance (salvage #34831) by benbarclay · Pull Request #36263 · NousResearch/hermes-agent

benbarclay · 2026-06-01T05:26:59Z

Summary

Salvage of #34831 (@donovan-yohan) — rebased onto current main with the trivial merge conflict resolved.

The dashboard's POST /api/hermes/update endpoint shelled out to hermes update unconditionally. Inside a Docker container that's an immutable image — the update can't apply, and the WebUI surfaced a raw SystemExit (#34347) while the user's real fix is docker pull (#35835).

This guards the endpoint: when detect_install_method() reports a docker install, it records a structured "not supported, run <command> instead" result (no subprocess spawned) and returns it to the WebUI, which renders actionable guidance instead of crashing.

Why a salvage

#34831 (donovan-yohan, the original) and #35339 (a byte-identical re-open) both conflicted against main — but only in tests/hermes_cli/test_web_server.py, where the new tests landed adjacent to other test additions made since. The production changes (web_server.py, web/src/lib/api.ts) auto-merged cleanly. This branch rebases onto current main and resolves the test conflict by keeping both test blocks.

Authorship preserved via Co-authored-by: Donovan Yohan.

Verification

Full tests/hermes_cli/test_web_server.py suite passes (191 tested), including the 5 dashboard-update-guard tests.
Dependencies (detect_install_method, format_docker_update_message, recommended_update_command_for_method) already present in hermes_cli/config.py.

Closes #34831. Closes #35339.

@donovan-yohan

…nce (salvage #34831) Salvage of #34831 (@donovan-yohan), rebased onto current main with the trivial test-file merge conflict resolved (the new tests landed adjacent to other test additions in test_web_server.py; kept both). The dashboard's POST /api/hermes/update endpoint shelled out to `hermes update` unconditionally. Inside a Docker container that is an immutable image — the update can't apply, and the WebUI surfaced a raw SystemExit (#34347) while the user's real fix is `docker pull` (#35835). This guards the endpoint: when detect_install_method() reports a docker install, it records a structured 'not supported, run <command> instead' result (no subprocess spawned) and returns it to the WebUI, which renders actionable guidance instead of a crash. Co-authored-by: Donovan Yohan <34756395+donovan-yohan@users.noreply.github.com>

github-actions · 2026-06-01T05:27:45Z

🔎 Lint report: `fix/dashboard-update-guard-docker-salvage-34831` vs `origin/main`

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 9572 on HEAD, 9572 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 4961 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

…lure (#34347) (#37085) The dashboard Update button's backend guard (#36263) already returns a structured {ok:false, error:"docker_update_unsupported", message, update_command} envelope (HTTP 200) when running in a Docker install, instead of surfacing a raw SystemExit. But the frontend ignored that envelope: runAction() only branched on a thrown error, so the 200 fell through to the action-status poll, which reported a generic "Action failed (exit 1)" toast and never showed the actual guidance. Now runAction() inspects the update response and, on the docker_update_unsupported case, surfaces the backend's guidance message plus the recommended re-pull command directly (success-styled, since it's actionable guidance — not a crash) without starting the poll. Closes #34347.

…lure (NousResearch#34347) (NousResearch#37085) The dashboard Update button's backend guard (NousResearch#36263) already returns a structured {ok:false, error:"docker_update_unsupported", message, update_command} envelope (HTTP 200) when running in a Docker install, instead of surfacing a raw SystemExit. But the frontend ignored that envelope: runAction() only branched on a thrown error, so the 200 fell through to the action-status poll, which reported a generic "Action failed (exit 1)" toast and never showed the actual guidance. Now runAction() inspects the update response and, on the docker_update_unsupported case, surfaces the backend's guidance message plus the recommended re-pull command directly (success-styled, since it's actionable guidance — not a crash) without starting the poll. Closes NousResearch#34347.

…nce (salvage #34831) (#36263) * fix: guard dashboard update in Docker * fix(dashboard): align action response type --------- Co-authored-by: Donovan Yohan <donovan-yohan@users.noreply.github.com> Co-authored-by: Donovan Yohan <34756395+donovan-yohan@users.noreply.github.com>

…lure (#34347) (#37085) The dashboard Update button's backend guard (#36263) already returns a structured {ok:false, error:"docker_update_unsupported", message, update_command} envelope (HTTP 200) when running in a Docker install, instead of surfacing a raw SystemExit. But the frontend ignored that envelope: runAction() only branched on a thrown error, so the 200 fell through to the action-status poll, which reported a generic "Action failed (exit 1)" toast and never showed the actual guidance. Now runAction() inspects the update response and, on the docker_update_unsupported case, surfaces the backend's guidance message plus the recommended re-pull command directly (success-styled, since it's actionable guidance — not a crash) without starting the poll. Closes #34347.

…nce (salvage NousResearch#34831) (NousResearch#36263) * fix: guard dashboard update in Docker * fix(dashboard): align action response type --------- Co-authored-by: Donovan Yohan <donovan-yohan@users.noreply.github.com> Co-authored-by: Donovan Yohan <34756395+donovan-yohan@users.noreply.github.com>