#143 from #140 #146

New issue

Closed

opened 2026-06-08 18:16:06 +00:00 by casper-stevens · 1 comment

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.

casper-stevens commented

2026-06-09 06:55:18 +00:00

Author

Member

Resolved on development; this is not reproducible on the current tip.

Findings:

The source this report blames no longer exists. The paths crates/hero_proc_server/oschema/jobs/30_job.oschema and 40_run.oschema, and the JobCreate.inputs / RunSpec.inputs {str: any} struct fields, are gone at HEAD. The schema was consolidated under schema/*.oschema and no longer models inputs as {str: any} struct fields.
The fix is already merged: ebf4a12 fix(jobs): model inputs as JSON string (Rule 2) (ref #143) changes the inputs to a JSON-string at the wire boundary, regenerates the spec, and updates the e2e test. This is exactly the suggested fix in this report, and it landed just before this issue was filed.
openrpc_client! consumes crates/hero_proc_server/openrpc.json, not the .oschema files. At HEAD that spec contains zero any type tokens (the free-form input map renders as additionalProperties: true, which the macro accepts), so the Schema::to_openrpc panic described here has nothing to trip on.

Latent note (not this issue): schema/job.oschema and schema/run.oschema still use {str: any} as method parameters. The committed openrpc.json is clean so nothing breaks today, but a future regeneration that runs validate_no_any_type could resurface it. That belongs to the ongoing oschema migration, separate from this report.

Closing as resolved.

Resolved on `development`; this is not reproducible on the current tip. Findings: - The source this report blames no longer exists. The paths `crates/hero_proc_server/oschema/jobs/30_job.oschema` and `40_run.oschema`, and the `JobCreate.inputs` / `RunSpec.inputs` `{str: any}` struct fields, are gone at HEAD. The schema was consolidated under `schema/*.oschema` and no longer models inputs as `{str: any}` struct fields. - The fix is already merged: `ebf4a12 fix(jobs): model inputs as JSON string (Rule 2)` (ref #143) changes the inputs to a JSON-string at the wire boundary, regenerates the spec, and updates the e2e test. This is exactly the suggested fix in this report, and it landed just before this issue was filed. - `openrpc_client!` consumes `crates/hero_proc_server/openrpc.json`, not the `.oschema` files. At HEAD that spec contains zero `any` type tokens (the free-form input map renders as `additionalProperties: true`, which the macro accepts), so the `Schema::to_openrpc` panic described here has nothing to trip on. Latent note (not this issue): `schema/job.oschema` and `schema/run.oschema` still use `{str: any}` as method parameters. The committed `openrpc.json` is clean so nothing breaks today, but a future regeneration that runs `validate_no_any_type` could resurface it. That belongs to the ongoing oschema migration, separate from this report. Closing as resolved.