#83 - Update all services to hero_proc_sdk latest — new required fields - lhumina_code/home

mik-tf commented

2026-03-23 21:23:53 +00:00

Owner

Problem

hero_proc added new required fields to ServiceStartInput and ServiceStopInput:

replace_existing_jobs (ServiceStartInput)
remove_jobs (ServiceStopInput)

Commits: bf4235c and aa41991 in hero_proc.

Every service that uses hero_proc_sdk now fails to compile:

error[E0063]: missing field `remove_jobs` in initializer of `ServiceStopInput`
error[E0063]: missing field `replace_existing_jobs` in initializer of `ServiceStartInput`

Affected repos

hero_services
hero_auth
hero_books
hero_foundry
hero_indexer (UI)
hero_inspector
hero_os
hero_osis
hero_proxy
hero_voice
hero_compute
hero_collab
hero_whiteboard

Fix

Add the new fields to every ServiceStartInput / ServiceStopInput initializer. Likely just remove_jobs: false and replace_existing_jobs: false as defaults.

Check hero_proc commit bf4235c for the field types and intended defaults.

Impact

Blocks full make dist builds. WASM builds are unaffected. Currently working around by using pre-built binaries from v0.7.2-dev.

## Problem hero_proc added new required fields to `ServiceStartInput` and `ServiceStopInput`: - `replace_existing_jobs` (ServiceStartInput) - `remove_jobs` (ServiceStopInput) Commits: `bf4235c` and `aa41991` in hero_proc. Every service that uses hero_proc_sdk now fails to compile: ``` error[E0063]: missing field `remove_jobs` in initializer of `ServiceStopInput` error[E0063]: missing field `replace_existing_jobs` in initializer of `ServiceStartInput` ``` ## Affected repos - hero_services - hero_auth - hero_books - hero_foundry - hero_indexer (UI) - hero_inspector - hero_os - hero_osis - hero_proxy - hero_voice - hero_compute - hero_collab - hero_whiteboard ## Fix Add the new fields to every `ServiceStartInput` / `ServiceStopInput` initializer. Likely just `remove_jobs: false` and `replace_existing_jobs: false` as defaults. Check hero_proc commit `bf4235c` for the field types and intended defaults. ## Impact Blocks full `make dist` builds. WASM builds are unaffected. Currently working around by using pre-built binaries from v0.7.2-dev.

mik-tf commented

2026-03-23 23:16:15 +00:00

Author

Owner

Status: 21/22 done — only hero_compute remains

Fixed and pushed

hero_services — 4 files, replace_existing_jobs: None + remove_jobs: None added
hero_foundry — version bump herolib_core/herolib_os 0.3.14 → 0.4 + build script fix (hero_foundry_admin removed)
hero_rpc — already fixed by other session
hero_whiteboard — refactored by other session (no longer uses raw ServiceStartInput)
hero_collab — refactored by other session (no longer uses raw ServiceStartInput)

Remaining: hero_compute

Root cause: hero_proc_sdk types are generated at compile time via openrpc_client! macro from hero_proc_server/openrpc.json. The macro reads the JSON spec and creates ServiceStartInput/ServiceStopInput structs. Even with local [patch] overrides pointing to the updated hero_proc, cargo's macro expansion resolves to stale generated types.

Error:

error[E0560]: struct `ServiceStartInput` has no field named `replace_existing_jobs`
error[E0560]: struct `ServiceStopInput` has no field named `remove_jobs`

Why it's tricky: The openrpc_client! macro in hero_proc_sdk/src/openrpc_client/mod.rs generates types from ../hero_proc_server/openrpc.json at compile time. The Docker build patches hero_proc_sdk to a local path, but the macro's relative path ../hero_proc_server/openrpc.json might resolve differently inside the Docker build context.

Likely fix: Run cargo update -p hero_proc_sdk inside hero_compute to refresh the lockfile, or ensure the Docker volume mount makes hero_proc_server/openrpc.json visible at the relative path the macro expects.

Impact: hero_compute (cloud VM management) is not critical for AI assistant, voice, or core Hero OS features. All other 21 services compile and run.

Signed-off-by: mik-tf

## Status: 21/22 done — only hero_compute remains ### Fixed and pushed - **hero_services** — 4 files, `replace_existing_jobs: None` + `remove_jobs: None` added - **hero_foundry** — version bump herolib_core/herolib_os 0.3.14 → 0.4 + build script fix (hero_foundry_admin removed) - **hero_rpc** — already fixed by other session - **hero_whiteboard** — refactored by other session (no longer uses raw ServiceStartInput) - **hero_collab** — refactored by other session (no longer uses raw ServiceStartInput) ### Remaining: hero_compute **Root cause**: `hero_proc_sdk` types are generated at compile time via `openrpc_client!` macro from `hero_proc_server/openrpc.json`. The macro reads the JSON spec and creates `ServiceStartInput`/`ServiceStopInput` structs. Even with local `[patch]` overrides pointing to the updated hero_proc, cargo's macro expansion resolves to stale generated types. **Error**: ``` error[E0560]: struct `ServiceStartInput` has no field named `replace_existing_jobs` error[E0560]: struct `ServiceStopInput` has no field named `remove_jobs` ``` **Why it's tricky**: The `openrpc_client!` macro in `hero_proc_sdk/src/openrpc_client/mod.rs` generates types from `../hero_proc_server/openrpc.json` at compile time. The Docker build patches `hero_proc_sdk` to a local path, but the macro's relative path `../hero_proc_server/openrpc.json` might resolve differently inside the Docker build context. **Likely fix**: Run `cargo update -p hero_proc_sdk` inside hero_compute to refresh the lockfile, or ensure the Docker volume mount makes `hero_proc_server/openrpc.json` visible at the relative path the macro expects. **Impact**: hero_compute (cloud VM management) is not critical for AI assistant, voice, or core Hero OS features. All other 21 services compile and run. Signed-off-by: mik-tf