fix(cli): forward PATH_ROOT and HERO_SOCKET_DIR to spawned daemons #20

Merged

mik-tf merged 1 commit from development_mik into development

2026-05-23 13:41:08 +00:00

mik-tf commented

2026-05-23 13:39:16 +00:00

Owner

Summary

hero_assistance --start previously brought up hero_assistance_server cleanly but left hero_assistance_ui and hero_assistance_admin stuck in retrying state, panicking on every spawn with PATH_ROOT is not set.

Root cause: hero_assistance_server happens to survive without PATH_ROOT because its startup path does not call herolib_core::base::prepare_sockets; the other two daemons do, and resolve_socket_dir falls through to path_var which calls path_root().expect(...) when HERO_SOCKET_DIR is unset in the child env. hero_proc inherits its own env when spawning children, so the operator's shell PATH_ROOT never reaches the daemon unless the service definition forwards it explicitly.

This is the same forward_env_if_set pattern already in place in hero_os, hero_indexer, hero_matrixchat, hero_wallet, hero_runner_rhai, hero_code_indexer, and hero_onboarding. hero_assistance just missed it.

Changes

New forward_env_if_set helper (10 LOC, same shape as the canonical pattern across the workspace)
New FORWARDED_ENV const = [PATH_ROOT, PATH_VAR, PATH_BUILD, PATH_CODE, HERO_SOCKET_DIR]
Three call sites in build_service_definition, one per action spec, after health_checks is set
New phase24c_build_service_definition_forwards_lesson19_env_to_all_actions unit test pinning the contract

Verification

Live: hero_assistance --start brings up all 3 daemons; curl --unix-socket app.sock / returns 200 with the customer SPA HTML, curl --unix-socket admin.sock / returns 200, curl --unix-socket rpc.sock /health returns 200. /proc/<child>/environ shows PATH_ROOT=/home/pctwo/hero propagated to all 3 children.

Workspace tests cargo test --release --workspace --no-fail-fast = 254 pass / 1 fail / 14 ignored, byte-stable vs the prior f22d819 baseline; the lone fail is the pre-existing host-env flake phase24b_ui_add_access_fails_when_hero_proc_unreachable. cargo fmt --check clean. cargo clippy --release --workspace --all-targets -- -D warnings clean.

Fixes #16

## Summary `hero_assistance --start` previously brought up `hero_assistance_server` cleanly but left `hero_assistance_ui` and `hero_assistance_admin` stuck in retrying state, panicking on every spawn with `PATH_ROOT is not set`. Root cause: `hero_assistance_server` happens to survive without PATH_ROOT because its startup path does not call `herolib_core::base::prepare_sockets`; the other two daemons do, and `resolve_socket_dir` falls through to `path_var` which calls `path_root().expect(...)` when `HERO_SOCKET_DIR` is unset in the child env. hero_proc inherits its own env when spawning children, so the operator's shell PATH_ROOT never reaches the daemon unless the service definition forwards it explicitly. This is the same `forward_env_if_set` pattern already in place in `hero_os`, `hero_indexer`, `hero_matrixchat`, `hero_wallet`, `hero_runner_rhai`, `hero_code_indexer`, and `hero_onboarding`. hero_assistance just missed it. ## Changes - New `forward_env_if_set` helper (10 LOC, same shape as the canonical pattern across the workspace) - New `FORWARDED_ENV` const = `[PATH_ROOT, PATH_VAR, PATH_BUILD, PATH_CODE, HERO_SOCKET_DIR]` - Three call sites in `build_service_definition`, one per action spec, after `health_checks` is set - New `phase24c_build_service_definition_forwards_lesson19_env_to_all_actions` unit test pinning the contract ## Verification Live: `hero_assistance --start` brings up all 3 daemons; `curl --unix-socket app.sock /` returns 200 with the customer SPA HTML, `curl --unix-socket admin.sock /` returns 200, `curl --unix-socket rpc.sock /health` returns 200. `/proc/<child>/environ` shows `PATH_ROOT=/home/pctwo/hero` propagated to all 3 children. Workspace tests `cargo test --release --workspace --no-fail-fast` = **254 pass / 1 fail / 14 ignored**, byte-stable vs the prior `f22d819` baseline; the lone fail is the pre-existing host-env flake `phase24b_ui_add_access_fails_when_hero_proc_unreachable`. `cargo fmt --check` clean. `cargo clippy --release --workspace --all-targets -- -D warnings` clean. Fixes https://forge.ourworld.tf/lhumina_code/hero_assistance/issues/16

mik-tf added 1 commit

2026-05-23 13:39:16 +00:00

fix(cli): forward PATH_ROOT and HERO_SOCKET_DIR to spawned daemons 86e2d53933

`hero_assistance --start` previously brought up _server cleanly but left
_ui and _admin stuck in retrying state, panicking on every spawn with
`PATH_ROOT is not set`. _server happens to survive without PATH_ROOT
because its startup path does not call `herolib_core::base::prepare_sockets`;
_ui and _admin do, and `resolve_socket_dir` falls through to `path_var`
which calls `path_root().expect(...)` when `HERO_SOCKET_DIR` is unset in
the child env. hero_proc inherits its own env when spawning children, so
the operator's shell `PATH_ROOT` never reaches the daemon unless the
service definition forwards it explicitly. This is the same Lesson #19
pattern already in place in hero_os, hero_indexer, hero_matrixchat,
hero_wallet, hero_runner_rhai, hero_code_indexer, and hero_onboarding.

Adds `forward_env_if_set` + `FORWARDED_ENV` const (PATH_ROOT, PATH_VAR,
PATH_BUILD, PATH_CODE, HERO_SOCKET_DIR) and calls it on all three action
specs in `build_service_definition`. Pins the contract with a new
`phase24c_build_service_definition_forwards_lesson19_env_to_all_actions`
unit test alongside the existing two phase24c_* tests.

Live verification: `hero_assistance --start` brings up all 3 daemons
(_server, _ui, _admin) on their sockets with PATH_ROOT propagated into
each child env; curl returns 200 on the customer SPA root, admin SPA
root, and _server /health. Workspace tests 254 pass / 1 fail / 14
ignored, byte-stable vs the prior `f22d819` baseline; the lone fail is
the pre-existing host-env flake `phase24b_ui_add_access_fails_when_hero_proc_unreachable`.

Fixes #16

Signed-by: mik-tf <mik-tf@noreply.invalid>