#143 from #140 #146

New issue

Open

opened 2026-06-08 18:16:06 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-06-08 18:16:06 +00:00

Member

Summary

hero_proc_sdk on the current development tip (14ee3ea, = #140 "restore typed inputs end-to-end") fails to compile when built against the current hero_lib development (277299dc). herolib_macros::openrpc_client! panics during macro expansion because the hero_proc schema uses the forbidden any type, which openrpc_client! now rejects per /openrpc_principles Rule 2.

This is a recurrence of the (closed) #142 / #143 ("openrpc_client! rejects {str: any} inputs from #140 — Rule 2"): #140 reintroduced {str: any} inputs, and the current hero_lib development macro enforces Rule 2 again.

Exact error

error: proc macro panicked
  --> hero_proc_sdk/src/openrpc_client/mod.rs:22:1
   |
22 | / openrpc_client!(
   | |     name = "HeroProcClient_", ...
   | |_^
   = help: message: Schema::to_openrpc: schema violates the method-input contract:
     schema validation failed with 2 `any`-type error(s):
       - type `JobCreate` uses the `any` type, which is forbidden ... (Rule 2)
       - type `RunSpec`  uses the `any` type, which is forbidden ... (Rule 2)

Because the macro panics it generates nothing, producing a cascade of downstream errors in the same crate: unresolved import HeroProcClient_, unresolved import jobs, unresolved import system, and the Action/RunSpec/ServiceSpec re-exports in builders.rs / factory.rs / lifecycle.rs / sse.rs.

Root cause (precise locations)

Both fields are {str: any}:

crates/hero_proc_server/oschema/jobs/30_job.oschema:49 — JobCreate.inputs: {str: any}
crates/hero_proc_server/oschema/jobs/40_run.oschema:46 — RunSpec.inputs: {str: any}

feeding job_create(req: JobCreate) and run_quick_submit(spec: RunSpec) in jobs/90_rpc.oschema:49,69.

Impact

Breaks every downstream consumer that pulls hero_proc development (with current hero_lib development). Concretely, hero_researcher (development→development per its branch policy) cannot build, which blocks the oschema/blueprint migration work for home#243 (see lhumina_code/hero_researcher#9).

Note: the integration branches of hero_lib + hero_proc build green together, so the fix is known there — but it has not reached hero_proc development. The development branch set is currently incoherent.

Reproduce

# any consumer pulling hero_proc + hero_lib development, e.g. hero_researcher on development:
cargo check -p hero_researcher_lib
# → proc macro panicked in hero_proc_sdk openrpc_client!

Revs: hero_proc 14ee3ea (#140), hero_lib 277299dc.

Suggested fix

Replace the {str: any} maps in JobCreate.inputs / RunSpec.inputs with a Rule-2-compliant shape (an explicit typed value struct, a scalar, or a homogeneous list — see /openrpc_principles), mirroring whatever resolution already lives on integration. Then verify with a downstream cargo check and re-run lab publish CI.

## Summary `hero_proc_sdk` on the current `development` tip (`14ee3ea`, = #140 "restore typed inputs end-to-end") **fails to compile** when built against the current `hero_lib` `development` (`277299dc`). `herolib_macros::openrpc_client!` **panics during macro expansion** because the hero_proc schema uses the forbidden `any` type, which `openrpc_client!` now rejects per `/openrpc_principles` Rule 2. This is a **recurrence of the (closed) #142 / #143** ("`openrpc_client!` rejects `{str: any}` inputs from #140 — Rule 2"): #140 reintroduced `{str: any}` inputs, and the current hero_lib `development` macro enforces Rule 2 again. ## Exact error ``` error: proc macro panicked --> hero_proc_sdk/src/openrpc_client/mod.rs:22:1 | 22 | / openrpc_client!( | | name = "HeroProcClient_", ... | |_^ = help: message: Schema::to_openrpc: schema violates the method-input contract: schema validation failed with 2 `any`-type error(s): - type `JobCreate` uses the `any` type, which is forbidden ... (Rule 2) - type `RunSpec` uses the `any` type, which is forbidden ... (Rule 2) ``` Because the macro panics it generates nothing, producing a cascade of downstream errors in the same crate: `unresolved import HeroProcClient_`, `unresolved import jobs`, `unresolved import system`, and the `Action`/`RunSpec`/`ServiceSpec` re-exports in `builders.rs` / `factory.rs` / `lifecycle.rs` / `sse.rs`. ## Root cause (precise locations) Both fields are `{str: any}`: - `crates/hero_proc_server/oschema/jobs/30_job.oschema:49` — `JobCreate.inputs: {str: any}` - `crates/hero_proc_server/oschema/jobs/40_run.oschema:46` — `RunSpec.inputs: {str: any}` feeding `job_create(req: JobCreate)` and `run_quick_submit(spec: RunSpec)` in `jobs/90_rpc.oschema:49,69`. ## Impact Breaks **every downstream consumer that pulls hero_proc `development`** (with current hero_lib `development`). Concretely, `hero_researcher` (development→development per its branch policy) cannot build, which blocks the oschema/blueprint migration work for `home#243` (see `lhumina_code/hero_researcher#9`). Note: the `integration` branches of hero_lib + hero_proc build green together, so the fix is known there — but it has not reached hero_proc `development`. The `development` branch set is currently incoherent. ## Reproduce ```sh # any consumer pulling hero_proc + hero_lib development, e.g. hero_researcher on development: cargo check -p hero_researcher_lib # → proc macro panicked in hero_proc_sdk openrpc_client! ``` Revs: hero_proc `14ee3ea` (#140), hero_lib `277299dc`. ## Suggested fix Replace the `{str: any}` maps in `JobCreate.inputs` / `RunSpec.inputs` with a Rule-2-compliant shape (an explicit typed value struct, a scalar, or a homogeneous list — see `/openrpc_principles`), mirroring whatever resolution already lives on `integration`. Then verify with a downstream `cargo check` and re-run lab publish CI.