hero_assistance --start does not spawn _admin or _ui child processes #16
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Running 'hero_assistance --start' from the CLI only spawns hero_assistance_server. The expected behavior, matching what lab service hero_assistance --start does via hero_proc, is to also spawn hero_assistance_ui and hero_assistance_admin as supervised children so the full demo surface is up. The dispatch logic lives in crates/hero_assistance/src/main.rs around the Start subcommand. The fix is to add the _admin and _ui actions to the start sequence alongside _server, mirroring how hero_proc's service definition does it.
Reproduced today against a fresh local install. With
PATH_ROOTset,hero_assistance --startregisters a single supervised service namedhero_assistancebut only spawnshero_assistance_server; the_adminand_uidaemons never start, so the customer UI at/hero_assistance/app/and the operator admin at/hero_assistance/admin/are both unreachable until they are started by hand. The call site iscrates/hero_assistance/src/main.rs:333(self_startcallshp.restart_service(SERVICE_NAME, service, 30)).build_service_definitioncorrectly returns aServiceBuildResultwith threeactions(server, ui, admin), and thephase24c_*unit tests at lines 1100 to 1180 pin those registrations, so the in-code action registration is intact; the runtime gap is thatrestart_serviceis only spawning the primary action. Two viable fix paths inside this repo: (a) iterate the three action names afterrestart_serviceand callhp.action_startforhero_assistance_uiandhero_assistance_admin; (b) re-shape the service definition so the auto-start contract on hero_proc's side picks up all three actions, and update thephase24c_*test gates accordingly. The per-component workaround (lab service hero_assistance_server --install --startplus the same for_adminand_ui) registers all three independently and passes smoke, so this issue blocks only the single-command operator flow, not the underlying stack.Recommended fix-owner: this repo (
lhumina_code/hero_assistance).Fixed in #20 (squash-merged as
49ea76a7on development).Root cause was the Lesson #19 trap:
build_service_definitiondidn't threadPATH_ROOTandHERO_SOCKET_DIRinto the action specs for the spawned daemons.hero_assistance_serverhappened to survive withoutPATH_ROOTbecause its startup path doesn't callherolib_core::base::prepare_sockets; the other two daemons do, andresolve_socket_dirfalls through topath_varwhich callspath_root().expect(...)whenHERO_SOCKET_DIRis unset in the child env. hero_proc spawns children with whatever env hero_proc_server itself has, so the operator's shellPATH_ROOTnever reached the daemons.Fix is the same
forward_env_if_setplusFORWARDED_ENVpattern already in hero_os, hero_indexer, hero_matrixchat, hero_wallet, hero_runner_rhai, hero_code_indexer, and hero_onboarding. Newphase24c_build_service_definition_forwards_lesson19_env_to_all_actionsunit test pins the contract.Verified live on this host:
hero_assistance --startbrought up all three daemons (server PID 3230295, ui PID 3232160, admin PID 3231628) withPATH_ROOT=/home/pctwo/heropropagated into each child env (confirmed via/proc/<pid>/environ). curl returned 200 on the customer SPA root via app.sock, on the admin SPA root via admin.sock, and on /health via rpc.sock.