[service_complete] --download tries to start cargo-only services (code/os/livekit), fails on ROOTDIR #233

New issue

Open

opened 2026-05-07 17:22:38 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-07 17:22:38 +00:00

Owner

Surfaced during session 74 from-nothing-on-DO validation.

Symptom

service_complete --download calls service_code start (and service_os, service_livekit) which fall through to the cargo-build install path because they don't accept --download. On a fresh public-cloud VM with no Rust toolchain, this fails:

✗ service_code: ROOTDIR not set. Run `init` first.
Error: service_code start failed — fix the error above and re-run.

Root cause

packages.nu service_complete definition has a comment listing four exceptions (code, codescalers, os, livekit) that "keep the cargo path — they have no Forgejo CI release pipeline today." codescalers is correctly skipped via the target == "driver" filter, but code, os, livekit are NOT skipped under --download — they're invoked without the flag and immediately fail.

Fix shape

After the starts_filtered line in service_complete, when $download is true, also filter out the cargo-only services:

let cargo_only = ["service_code", "service_os", "service_livekit"]
let starts = if $download {
    $starts_filtered | where { |s| ($cargo_only | any { |n| $n == $s.name }) == false }
} else {
    $starts_filtered
}

Validated as a hand-patch on the session-74 droplet — bring-up went from 0/N to 14/17 services running.

Severity

High — blocks every public-cloud --download deploy until the operator hand-patches.

Filed as part of home#227 follow-ups.

Surfaced during session 74 from-nothing-on-DO validation. ## Symptom `service_complete --download` calls `service_code start` (and `service_os`, `service_livekit`) which fall through to the cargo-build install path because they don't accept `--download`. On a fresh public-cloud VM with no Rust toolchain, this fails: ``` ✗ service_code: ROOTDIR not set. Run `init` first. Error: service_code start failed — fix the error above and re-run. ``` ## Root cause `packages.nu` `service_complete` definition has a comment listing four exceptions (`code`, `codescalers`, `os`, `livekit`) that "keep the cargo path — they have no Forgejo CI release pipeline today." `codescalers` is correctly skipped via the `target == "driver"` filter, but `code`, `os`, `livekit` are NOT skipped under `--download` — they're invoked without the flag and immediately fail. ## Fix shape After the `starts_filtered` line in `service_complete`, when `$download` is true, also filter out the cargo-only services: ```nu let cargo_only = ["service_code", "service_os", "service_livekit"] let starts = if $download { $starts_filtered | where { |s| ($cargo_only | any { |n| $n == $s.name }) == false } } else { $starts_filtered } ``` Validated as a hand-patch on the session-74 droplet — bring-up went from 0/N to 14/17 services running. ## Severity High — blocks every public-cloud `--download` deploy until the operator hand-patches. Filed as part of [home#227](https://forge.ourworld.tf/lhumina_code/home/issues/227) follow-ups.