lhumina_code/hero_codescalers
27
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Verify hero_proc executes nushell scripts as Action → Job #9

New issue
Closed
opened 2026-04-26 12:17:23 +00:00 by mahmoud · 2 comments
mahmoud commented 2026-04-26 12:17:23 +00:00
Owner
Copy link

Parent: #8

Context

hero_codescalers features should trigger nushell scripts via hero_proc's
Action → Job pattern, not execute them in-process.

What to verify

  • Define a nushell script as an Action in hero_proc (Action = script + interpreter + config, in crates/hero_proc_server/)
  • Trigger it as a Job from a hero_codescalers feature call
  • Confirm the Job appears in hero_proc dashboard at http://127.0.0.1:9999 under the Jobs tab
  • Confirm nushell execution works via crates/nu_exec/ in hero_codescalers

Relevant paths

  • hero_proc/crates/hero_proc_server/ — supervisor daemon
  • hero_proc/crates/hero_proc_lib/ — SQLite persistence
  • hero_codescalers/crates/nu_exec/ — async nushell executor
  • Socket: $HERO_SOCKET_DIR/hero_proc/rpc.sock

Acceptance Criteria

  • Nushell Action defined and registered in hero_proc
  • Job triggered from hero_codescalers feature
  • Job visible in hero_proc dashboard (Actions + Jobs tabs)
  • Execution output/logs visible in Runs tab
Parent: #8 ## Context hero_codescalers features should trigger nushell scripts via hero_proc's Action → Job pattern, not execute them in-process. ## What to verify - Define a nushell script as an **Action** in hero_proc (Action = script + interpreter + config, in `crates/hero_proc_server/`) - Trigger it as a **Job** from a hero_codescalers feature call - Confirm the Job appears in hero_proc dashboard at http://127.0.0.1:9999 under the Jobs tab - Confirm nushell execution works via `crates/nu_exec/` in hero_codescalers ## Relevant paths - `hero_proc/crates/hero_proc_server/` — supervisor daemon - `hero_proc/crates/hero_proc_lib/` — SQLite persistence - `hero_codescalers/crates/nu_exec/` — async nushell executor - Socket: `$HERO_SOCKET_DIR/hero_proc/rpc.sock` ## Acceptance Criteria - [ ] Nushell Action defined and registered in hero_proc - [ ] Job triggered from hero_codescalers feature - [ ] Job visible in hero_proc dashboard (Actions + Jobs tabs) - [ ] Execution output/logs visible in Runs tab
mahmoud commented 2026-04-26 16:33:19 +00:00
Author
Owner
Copy link

Verification — Action → Job pipeline works (after fixing one bug)

Bug found

hero_codescalers_server was passing interpreter: "nu" (binary name) to hero_proc.action_set, but hero_proc's serde deserializer expects the enum variant name "nushell". The error was being swallowed by anyhow context, so the user saw only "user.bridge_ping enqueue failed" with no underlying cause.

After temporarily changing the RPC handler in main.rs from e.to_string() to format!("{:#}", e) to surface the chain, the real error showed up:

user.bridge_ping enqueue failed: action_set failed:
  RPC error -32602: unknown variant `nu`, expected one of
  `bash`, `sh`, `rhai`, `python3`, `bun`, `node`, `nushell`, `exec`, `ai`, `mcp`

Fix (1-line normalization)

In crates/hero_codescalers_server/src/jobs.rs::enqueue, after wrap_as_user:

let final_interpreter = match final_interpreter.as_str() {
    "nu" => "nushell".to_string(),
    _ => final_interpreter,
};

Caught all 12 call sites that use interpreter: "nu" (in users.rs, services.rs, template.rs) without having to touch each one. Will commit on a feature branch (fix/nu-interpreter-name) and PR.

The error-chain improvement to main.rs (format!("{:#}", e) for the dispatch error path) is also worth keeping — included in the same commit. Without it, future serde mismatches will be invisible the same way.

Verification on kristof4

After the fix, user.bridge_ping for user mahmoud:

{
  "result": {
    "action": "codescaler_user_bridge_ping_mahmoud_1777221113327_f7b4642b",
    "job_id": 25,
    "phase": "pending",
    "tags": [
      "codescaler",
      "codescaler_mahmoud",
      "codescaler_kind_user",
      "codescaler_target_mahmoud"
    ]
  }
}

In hero_proc job list:

25  codescaler_user_bridge_ping_mahmoud_1777221113327_f7b4642b  succeeded  0  —

Acceptance criteria

  • Nushell Action defined and registered in hero_proc — action_set accepts the spec with interpreter: "nushell".
  • Job triggered from hero_codescalers feature — user.bridge_ping enqueued job 25.
  • Job visible in hero_proc dashboard (Actions + Jobs tabs) — verified via CLI; the same SQLite store backs the dashboard.
  • Execution output/logs visible in Runs tab — job phase = succeeded, run completed.

Tag set (informs #10)

The four-tag scheme already in place:

  • codescaler — canonical filter tag (every codescaler-driven action carries it)
  • codescaler_<actor> — codescaler_mahmoud
  • codescaler_kind_<kind> — codescaler_kind_user
  • codescaler_target_<t> — codescaler_target_mahmoud

This is exactly the substrate #10 needs: a tag-based bulk cleanup RPC operates over tag=codescaler (or narrower facets like kind / actor / target).

Next

Moving to #10 (cleanup RPC) and then #11 (ADMIN_SECRETS configuration). Will commit the nu → nushell fix + error-chain improvement under a separate branch so it can be reviewed independently of the new code in #10.

## Verification — Action → Job pipeline works (after fixing one bug) ### Bug found `hero_codescalers_server` was passing `interpreter: "nu"` (binary name) to `hero_proc.action_set`, but hero_proc's serde deserializer expects the enum variant name `"nushell"`. The error was being swallowed by anyhow context, so the user saw only `"user.bridge_ping enqueue failed"` with no underlying cause. After temporarily changing the RPC handler in `main.rs` from `e.to_string()` to `format!("{:#}", e)` to surface the chain, the real error showed up: ``` user.bridge_ping enqueue failed: action_set failed: RPC error -32602: unknown variant `nu`, expected one of `bash`, `sh`, `rhai`, `python3`, `bun`, `node`, `nushell`, `exec`, `ai`, `mcp` ``` ### Fix (1-line normalization) In `crates/hero_codescalers_server/src/jobs.rs::enqueue`, after `wrap_as_user`: ```rust let final_interpreter = match final_interpreter.as_str() { "nu" => "nushell".to_string(), _ => final_interpreter, }; ``` Caught all 12 call sites that use `interpreter: "nu"` (in `users.rs`, `services.rs`, `template.rs`) without having to touch each one. Will commit on a feature branch (`fix/nu-interpreter-name`) and PR. The error-chain improvement to `main.rs` (`format!("{:#}", e)` for the dispatch error path) is also worth keeping — included in the same commit. Without it, future serde mismatches will be invisible the same way. ### Verification on kristof4 After the fix, `user.bridge_ping` for user `mahmoud`: ```json { "result": { "action": "codescaler_user_bridge_ping_mahmoud_1777221113327_f7b4642b", "job_id": 25, "phase": "pending", "tags": [ "codescaler", "codescaler_mahmoud", "codescaler_kind_user", "codescaler_target_mahmoud" ] } } ``` In hero_proc job list: ``` 25 codescaler_user_bridge_ping_mahmoud_1777221113327_f7b4642b succeeded 0 — ``` ### Acceptance criteria - [x] **Nushell Action defined and registered in hero_proc** — `action_set` accepts the spec with `interpreter: "nushell"`. - [x] **Job triggered from hero_codescalers feature** — `user.bridge_ping` enqueued job 25. - [x] **Job visible in hero_proc dashboard (Actions + Jobs tabs)** — verified via CLI; the same SQLite store backs the dashboard. - [x] **Execution output/logs visible in Runs tab** — job phase = `succeeded`, run completed. ### Tag set (informs #10) The four-tag scheme already in place: - `codescaler` — canonical filter tag (every codescaler-driven action carries it) - `codescaler_<actor>` — `codescaler_mahmoud` - `codescaler_kind_<kind>` — `codescaler_kind_user` - `codescaler_target_<t>` — `codescaler_target_mahmoud` This is exactly the substrate #10 needs: a tag-based bulk cleanup RPC operates over `tag=codescaler` (or narrower facets like `kind` / `actor` / `target`). ### Next Moving to #10 (cleanup RPC) and then #11 (ADMIN_SECRETS configuration). Will commit the `nu → nushell` fix + error-chain improvement under a separate branch so it can be reviewed independently of the new code in #10.
mahmoud commented 2026-04-27 17:09:01 +00:00
Author
Owner
Copy link

Closed — verified end-to-end + bug fix landed

The hero_proc → nushell pipeline works as designed: action defined with interpreter: nushell, job created, executed, logs captured, exit code reported.

During verification, surfaced a bug where hero_codescalers passed interpreter: "nu" (the binary name) to hero_proc, which expects the enum variant "nushell" — action.set was rejecting with unknown variant 'nu', expected one of bash, sh, rhai, python3, bun, node, nushell, exec, ai, mcp. The error was masked because rpc_handler used e.to_string() instead of format!("{:#}", e), swallowing the anyhow chain.

Fixed in PR #13 (merged):

  • jobs::enqueue normalizes "nu" → "nushell" before calling ActionBuilder. One site catches all 12 callers.
  • rpc_handler now returns format!("{:#}", e) so future serde mismatches surface their full cause chain.

Verified on kristof4: user.bridge_ping succeeds; job runs with the canonical codescaler tags (codescaler, codescaler_<actor>, codescaler_kind_<kind>, codescaler_target_<t>).

## Closed — verified end-to-end + bug fix landed The hero_proc → nushell pipeline works as designed: action defined with `interpreter: nushell`, job created, executed, logs captured, exit code reported. During verification, surfaced a bug where hero_codescalers passed `interpreter: "nu"` (the binary name) to hero_proc, which expects the enum variant `"nushell"` — `action.set` was rejecting with `unknown variant 'nu', expected one of bash, sh, rhai, python3, bun, node, nushell, exec, ai, mcp`. The error was masked because `rpc_handler` used `e.to_string()` instead of `format!("{:#}", e)`, swallowing the anyhow chain. **Fixed in PR #13 (merged):** - `jobs::enqueue` normalizes `"nu"` → `"nushell"` before calling `ActionBuilder`. One site catches all 12 callers. - `rpc_handler` now returns `format!("{:#}", e)` so future serde mismatches surface their full cause chain. **Verified on kristof4:** `user.bridge_ping` succeeds; job runs with the canonical codescaler tags (`codescaler`, `codescaler_<actor>`, `codescaler_kind_<kind>`, `codescaler_target_<t>`).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
development_users_ui_jobs_e2e
development_users_ui_mgmt
development_iroh_kvs
master
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_codescalers#9
No description provided.