dream template apply: exits on library extension instead of skipping (cmd_enable calls exit 1, uncatchable by || warn)

[yasinBursali]

Bug Report: dream template apply aborts on library extension instead of warning and continuing

Severity: High
Category: Error Handling
Platform: All (macOS, Linux, Windows/WSL2)
Confidence: Confirmed

Description

dream template apply <template-id> exits with code 1 and a misleading "Unknown service" error when the template includes a library extension that has not been installed yet. The _template_apply function uses cmd_enable "$svc" || warn "..." expecting a non-zero return code on failure, but cmd_enable internally calls error() which calls exit 1. An exit 1 cannot be caught by || — it terminates the entire shell process. Built-in extensions with compose.yaml.disabled are not affected; only library extensions (those in resources/dev/extensions-library/) trigger this path.

Affected File(s)

• dream-server/dream-cli (lines 3027–3042 — _template_apply)
• dream-server/dream-cli (line 48 — error() definition: error() { echo -e "${RED}✗${NC} $1"; exit 1; })

Root Cause

# _template_apply, lines 3040-3041
log "  Enabling $svc..."
cmd_enable "$svc" || warn "  Failed to enable $svc (continuing)"

When $svc is a library extension not yet installed (e.g., aider, gitea, chromadb), cmd_enable hits:

# cmd_enable — directory existence check
local ext_dir="$INSTALL_DIR/extensions/services/$service_id"
[[ ! -d "$ext_dir" ]] && ext_dir="$INSTALL_DIR/data/user-extensions/$service_id"
[[ -d "$ext_dir" ]] || error "Unknown service: $input"  # ← calls exit 1

error() runs exit 1, which terminates the entire shell. The || warn in _template_apply only catches non-zero return codes — it cannot intercept exit 1.

Evidence

# Line 48 of dream-cli — exit 1 is unconditional
error() { echo -e "${RED}✗${NC} $1"; exit 1; }

# _template_apply calls cmd_enable and expects || to handle failure
cmd_enable "$svc" || warn "  Failed to enable $svc (continuing)"
# BUT: if cmd_enable calls error(), exit 1 kills the whole process —
#       || warn is never reached

Platform Analysis

• macOS: Affected — dream-cli runs under Homebrew bash 4+ (after PR fix(macos-installer): guard Bash 4+ and auto-install via Homebrew Light-Heart-Labs/DreamServer#889 guard). Same code path.
• Linux: Affected — dream-cli runs under system bash 4+. Same code path.
• Windows/WSL2: Affected — dream-cli runs under WSL2 bash. Same code path.

Reproduction

1. Fresh install or any system where library extensions are not yet installed
2. Run: dream template apply ai-coding-workspace
3. Template services: [aider, gitea, chromadb, n8n, openclaw]
4. aider is a library extension not in extensions/services/ or data/user-extensions/
5. cmd_enable "aider" → error "Unknown service: aider" → exit 1
6. Expected: Warning printed, aider skipped, n8n and openclaw (built-in) still enabled
7. Actual: Shell exits with code 1, n8n and openclaw never enabled, no success message

Impact

10 out of 11 built-in templates include at least one library extension (aider, gitea, chromadb, librechat, flowise, langflow, crewai, label-studio, paperless-ngx, piper-audio, sillytavern, open-interpreter, baserow). The only unaffected template is creative-studio (GPU-only, all built-in services). dream template apply is effectively broken for all standard templates when library extensions are not pre-installed.

Suggested Approach

Wrap the cmd_enable call in a subshell (cmd_enable "$svc") || warn "..." so that exit 1 inside cmd_enable terminates only the subshell, not the parent. Alternatively, pre-check for the extension directory existence before calling cmd_enable and emit a clear "not installable from CLI — use dashboard" message for library extensions.

---

Filed by automated shell auditor after full-sweep review of shell changes merged 2026-04-06 → 2026-04-11. Commit range inspected: upstream/main @ c0600ca.

[yasinBursali]

Addressed by upstream draft PR Light-Heart-Labs#903.

[yasinBursali]

Verified at runtime — PR Light-Heart-Labs#903's subshell wrap holds on the integration branch

Environment: WSL2 / Ubuntu 24.04 / NVIDIA RTX 3070 Laptop / Tier 1
Branch: local/integration-test (PR stack Light-Heart-Labs#893–909 merged onto Light-Heart-Labs/DreamServer@c0600ca)
Install: bash install.sh --all --non-interactive --no-comfyui → phase 13, 17 healthy containers

What I tested

Source-level inspection of the deployed dream-cli to confirm the subshell wrap is in place at the template-apply per-extension call site.

Result

$ sed -n '3035,3045p' /home/rosenrot/dream-server/dream-cli
            log "  $svc — already enabled"
            continue
        fi

        log "  Enabling $svc..."
        ( cmd_enable "$svc" ) || warn "  Failed to enable $svc (continuing)"
    done
    success "Template applied: $template_id"
}

Line 3040: ( cmd_enable "$svc" ) || warn "...". The subshell wrap means cmd_enable's exit status no longer kills the parent loop on a failing extension; the loop continues and the failure is logged via warn. Exactly what this issue asked for.

Status

PR Light-Heart-Labs#903's fix holds. This issue can stay closed.

What was NOT tested at runtime

End-to-end "apply a template with a deliberately-broken extension and observe the rest still apply." The trickle-up problem is that template apply itself is currently blocked by an unrelated issue on the integration branch — see #331 (the Light-Heart-Labs#908+Light-Heart-Labs#909 :ro mount conflict that 500s every template apply). Once #331 is fixed and template apply reaches the per-extension loop, this PR's subshell wrap will be exercised in the wild. Until then the fix is verified at the source-line level only.

If you want me to test this in isolation against just the _template_apply shell function (without going through the dashboard-api / template-apply HTTP path), I can drive dream-cli directly with a stub template — say so.

---

Verified during full-stack integration test of open PR stack Light-Heart-Labs#893–909.

[yasinBursali]

Follow-up: real end-to-end test via dream template apply

In my earlier comment I noted I had source-line evidence at L3040 but had not exercised the loop end-to-end with a real failing extension. Just did that, and the result is exactly as designed.

Test

Ran dream template apply developer-homelab against the integration branch. This template's services list is [gitea, aider, baserow, n8n, token-spy]. Pre-state on the test system:

Service	Built-in path	User-extensions path	Expected behavior
gitea	absent	absent	cmd_enable errors → subshell catches → continue
aider	absent	absent	cmd_enable errors → subshell catches → continue
baserow	absent	present (installed earlier in this test pass)	"already enabled" skip
n8n	present (built-in default install)	absent	"already enabled" skip
token-spy	present (built-in default install)	absent	"already enabled" skip

Result

$ dream template apply developer-homelab
[dream] Applying template: developer-homelab
[dream]   Enabling gitea...
✗ Unknown service: gitea
⚠   Failed to enable gitea (continuing)        ← subshell caught the error, loop continues
[dream]   Enabling aider...
✗ Unknown service: aider
⚠   Failed to enable aider (continuing)        ← subshell caught the error, loop continues
[dream]   baserow — already enabled
[dream]   n8n — already enabled
[dream]   token-spy — already enabled
✓ Template applied: developer-homelab
elapsed: 1s

What this proves

• The loop continues past failures. Two Unknown service errors fired (gitea + aider, both library extensions not installed on this system), and the ( cmd_enable "$svc" ) || warn subshell at L3040 caught each one cleanly. The loop didn't bail out — it iterated through all 5 services in the template.
• Pre-existing services correctly hit the skip path (baserow, n8n, token-spy all logged "already enabled" via the if [[ -f "$cf" || -f "$ucf" ]]; then ... continue branch above the cmd_enable call).
• The success message fires at the end. ✓ Template applied: developer-homelab is logged regardless of the 2 failures.
• Total runtime: 1 second — no hanging, no stalls, no rollback path triggered. The fix is exactly as designed.

Confirms the static-review flag too

PR Light-Heart-Labs#903's static review noted that partial success is silent: "the success message fires regardless of how many extensions failed." This runtime test confirms it: the operator sees ✗ and ⚠ lines for the 2 failed extensions, but the trailing ✓ Template applied doesn't say "3 enabled, 2 failed" — it just says success. For optional extension templates this is acceptable UX; for templates with mandatory dependencies it could mask real problems.

Worth a follow-up to add a {N} enabled, {M} failed summary line to _template_apply so the operator gets an explicit count without having to grep the log for ⚠. Mentioning here for tracking — I won't open a separate issue unless you want me to.

Status

PR Light-Heart-Labs#903's fix works end-to-end. This issue can stay closed.

---

Verified during full-stack integration test of open PR stack Light-Heart-Labs#893–909.