fix(secrets): hero_proc secret CLI sends wrong RPC params for every subcommand #52

New issue

Closed

opened 2026-04-27 16:21:46 +00:00 by omarz · 1 comment

omarz commented

2026-04-27 16:21:46 +00:00

Member

Context

Every hero_proc secret CLI subcommand is wired to the wrong RPC param shape, so the only way to manage secrets today is via the web UI or raw JSON-RPC. The server-side handlers (crates/hero_proc_server/src/rpc/secret.rs) expect:

RPC	Params
`secret.set`	`{ "secret": { "context_name", "key", "value", "description"?, "tags"? } }` (or inline)
`secret.get`	`{ "context": "core", "key": "..." }`
`secret.list`	`{ "filter": SecretFilter }` (or inline / empty) → returns `{ "secrets": [Secret] }`
`secret.delete`	`{ "context": "core", "key": "..." }`
`secret.pull` / `secret.push`	`{ "forge_token": "..." }`

The CLI (crates/hero_proc/src/cli/commands.rs:869-924) sends { "name": ... } for set/get/delete, sends {} for list and parses the response as Vec<String> (server returns {secrets:[...]}), and sends {} for pull/push (no token).

Symptoms reproduced today:

~> hero_proc secret list
No secrets configured                    # always — even when there are 50+ secrets
~> hero_proc secret delete ADMIN_SECRETS
Error: Failed to delete secret: RPC error -32602: missing 'key' parameter
~> hero_proc secret get ADMIN_SECRETS
Error: Failed to get secret: RPC error -32602: missing 'key' parameter

The web UI (crates/hero_proc_ui/static/js/dashboard.js) already uses the correct shapes, so this is purely a CLI defect.

Goals

hero_proc secret <set|get|list|delete> accept a --context <name> flag (default core) and send the correct RPC params.
secret set accept optional --description <text> and repeatable --tag <name>, and wrap the payload as { "secret": {...} }.
secret list accept optional --context, --filter <pattern>, and --tag flags; parse the {secrets:[...]} response and render a table with key, context, tags, and (with -v) value/description.
secret get print the full record (key, context, value, description, tags) — currently it prints only the bare value if it deserializes at all.
secret pull and secret push forward FORGE_TOKEN (or FORGEJO_TOKEN) from the environment as the forge_token RPC param, with a clear error if neither is set.
All commands keep honoring the global --format/-q/-v flags.
Smoke-tested end to end against a running daemon: set → list → get → delete round-trip.

## Context Every `hero_proc secret` CLI subcommand is wired to the wrong RPC param shape, so the only way to manage secrets today is via the web UI or raw JSON-RPC. The server-side handlers (`crates/hero_proc_server/src/rpc/secret.rs`) expect: | RPC | Params | |---|---| | `secret.set` | `{ "secret": { "context_name", "key", "value", "description"?, "tags"? } }` (or inline) | | `secret.get` | `{ "context": "core", "key": "..." }` | | `secret.list` | `{ "filter": SecretFilter }` (or inline / empty) → returns `{ "secrets": [Secret] }` | | `secret.delete` | `{ "context": "core", "key": "..." }` | | `secret.pull` / `secret.push` | `{ "forge_token": "..." }` | The CLI (`crates/hero_proc/src/cli/commands.rs:869-924`) sends `{ "name": ... }` for set/get/delete, sends `{}` for list and parses the response as `Vec<String>` (server returns `{secrets:[...]}`), and sends `{}` for pull/push (no token). Symptoms reproduced today: ``` ~> hero_proc secret list No secrets configured # always — even when there are 50+ secrets ~> hero_proc secret delete ADMIN_SECRETS Error: Failed to delete secret: RPC error -32602: missing 'key' parameter ~> hero_proc secret get ADMIN_SECRETS Error: Failed to get secret: RPC error -32602: missing 'key' parameter ``` The web UI (`crates/hero_proc_ui/static/js/dashboard.js`) already uses the correct shapes, so this is purely a CLI defect. ## Goals - `hero_proc secret <set|get|list|delete>` accept a `--context <name>` flag (default `core`) and send the correct RPC params. - `secret set` accept optional `--description <text>` and repeatable `--tag <name>`, and wrap the payload as `{ "secret": {...} }`. - `secret list` accept optional `--context`, `--filter <pattern>`, and `--tag` flags; parse the `{secrets:[...]}` response and render a table with key, context, tags, and (with `-v`) value/description. - `secret get` print the full record (key, context, value, description, tags) — currently it prints only the bare value if it deserializes at all. - `secret pull` and `secret push` forward `FORGE_TOKEN` (or `FORGEJO_TOKEN`) from the environment as the `forge_token` RPC param, with a clear error if neither is set. - All commands keep honoring the global `--format`/`-q`/`-v` flags. - Smoke-tested end to end against a running daemon: set → list → get → delete round-trip.