[bug] service_install_all references service_lib_rhai but no such module exists — install_all aborts on 6th service #186

New issue

Open

opened 2026-05-01 15:55:23 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-01 15:55:23 +00:00

Owner

Summary

service_install_all in tools/modules/services/packages.nu references service_lib_rhai 5 times but no matching service_lib_rhai.nu module exists in tools/modules/services/, and there's no use service_lib_rhai.nu at the top of the file. nu falls through trying to execute it as an external command, which fails with:

✗ service_lib_rhai: External command failed
Error: nu::shell::error
  x service_lib_rhai failed — stopping. Fix the error above and re-run.

This blocks service_install_all deterministically on the 6th iteration (services_core[6]), aborting before any of the services_extra services get a chance to install.

Hit live during a herodemo deploy on 2026-05-01.

Source

tools/modules/services/packages.nu:67 — service_lib_rhai entry in services_core
Lines 167, 191 — comments referring to "install-only library" and "minus service_lib_rhai" suggest the intent was to build the rhai library crates without registering them as runtime services
tools/modules/services/ — only contains service_runner_rhai.nu, no service_lib_rhai.nu
lhumina_code/hero_lib_rhai — exists as a Cargo workspace with library + service-runner crates

Fix options

Option A: create service_lib_rhai.nu that does cargo build --release on the library crates of hero_lib_rhai (excluding the runner_rhai service crates which service_runner_rhai.nu already handles). Add the matching use service_lib_rhai.nu at the top of packages.nu. Cleanest if the intent is genuinely to ship binaries from this workspace.

Option B: remove service_lib_rhai from services_core and rely on service_runner_rhai (already in the list) plus transitive cargo build to pull the library crates as deps when other services need them. Simplest if the rhai libraries are only consumed as Cargo deps and don't need standalone build/install.

Pick the one that matches the original design intent. The comment at line 167 ("install-only, no runtime") suggests Option A was the intent, but Option B may also be correct given how the dependent services already build their rhai deps transitively.

Workaround used on herodemo

Locally commented out the service_lib_rhai line at packages.nu:67 to unblock service_install_all. NOT pushed upstream — local-only on the herodemo VM. Will conflict on next manual git pull of hero_skills.

Meta-observation

This is the third deploy-blocking bug found today during a single service_install_all run, after hero_router#81 (/Volumes/T7 path leak) and hero_proc#91 (CREATE INDEX before ALTER TABLE). Suggests service_install_all hasn't been end-to-end exercised on a clean machine in a while.

Worth considering: a CI job that runs service_install_all --update --release against a fresh VM image weekly, to catch this class of regression before someone needs to deploy under pressure.

## Summary `service_install_all` in [`tools/modules/services/packages.nu`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/tools/modules/services/packages.nu) references `service_lib_rhai` 5 times but no matching `service_lib_rhai.nu` module exists in `tools/modules/services/`, and there's no `use service_lib_rhai.nu` at the top of the file. nu falls through trying to execute it as an external command, which fails with: ``` ✗ service_lib_rhai: External command failed Error: nu::shell::error x service_lib_rhai failed — stopping. Fix the error above and re-run. ``` This blocks `service_install_all` deterministically on the 6th iteration (`services_core[6]`), aborting before any of the `services_extra` services get a chance to install. Hit live during a herodemo deploy on 2026-05-01. ## Source - [`tools/modules/services/packages.nu:67`](https://forge.ourworld.tf/lhumina_code/hero_skills/src/branch/development/tools/modules/services/packages.nu#L67) — `service_lib_rhai` entry in `services_core` - Lines 167, 191 — comments referring to "install-only library" and "minus service_lib_rhai" suggest the intent was to build the rhai library crates without registering them as runtime services - `tools/modules/services/` — only contains `service_runner_rhai.nu`, no `service_lib_rhai.nu` - `lhumina_code/hero_lib_rhai` — exists as a Cargo workspace with library + service-runner crates ## Fix options **Option A: create `service_lib_rhai.nu`** that does `cargo build --release` on the library crates of `hero_lib_rhai` (excluding the runner_rhai service crates which `service_runner_rhai.nu` already handles). Add the matching `use service_lib_rhai.nu` at the top of `packages.nu`. Cleanest if the intent is genuinely to ship binaries from this workspace. **Option B: remove `service_lib_rhai` from `services_core`** and rely on `service_runner_rhai` (already in the list) plus transitive `cargo build` to pull the library crates as deps when other services need them. Simplest if the rhai libraries are only consumed as Cargo deps and don't need standalone build/install. Pick the one that matches the original design intent. The comment at line 167 ("install-only, no runtime") suggests Option A was the intent, but Option B may also be correct given how the dependent services already build their rhai deps transitively. ## Workaround used on herodemo Locally commented out the `service_lib_rhai` line at packages.nu:67 to unblock `service_install_all`. NOT pushed upstream — local-only on the herodemo VM. Will conflict on next manual `git pull` of hero_skills. ## Meta-observation This is the third deploy-blocking bug found today during a single `service_install_all` run, after [hero_router#81](https://forge.ourworld.tf/lhumina_code/hero_router/issues/81) (`/Volumes/T7` path leak) and [hero_proc#91](https://forge.ourworld.tf/lhumina_code/hero_proc/issues/91) (CREATE INDEX before ALTER TABLE). Suggests `service_install_all` hasn't been end-to-end exercised on a clean machine in a while. Worth considering: a CI job that runs `service_install_all --update --release` against a fresh VM image weekly, to catch this class of regression before someone needs to deploy under pressure.