lhumina_code/hero_rpc
1
0
Fork 0
Code Issues 18 Pull requests Projects Releases 1 Packages Wiki Activity Actions

Regenerate per-domain openrpc.json from .oschema during cargo build #41

New issue
Closed
opened 2026-05-05 11:25:56 +00:00 by timur · 2 comments
timur commented 2026-05-05 11:25:56 +00:00
Owner
Copy link

Audit results (downscoped)

Verified the proposed pattern already works end-to-end:

  • OschemaBuilder::generate() (called from a service crate's build.rs) writes the per-domain openrpc.json via Generator::generate_domain_files (crates/generator/src/generate.rs:404-411).
  • cargo:rerun-if-changed=... is emitted for the schemas dir + each .oschema file (crates/generator/src/build/build.rs:926, 931).
  • Verified live: touch crates/hero_logic/schemas/logic/logic.oschema && cargo build -p hero_logic regenerates src/logic/core/openrpc.json. include_str! then captures the new content on the next compile.

So the infrastructure for build-time regen is already in place. The issue was misdiagnosed as "missing feature" — it's "incomplete adoption."

Audit of consumer crates

Crate .oschema? build.rs? Status
hero_logic yes yes ✓
hero_osis yes yes ✓
hero_compute_manager yes yes ✓
hero_whiteboard yes (3 schemas) no needs backfill
hero_fossil yes (1 schema) no needs backfill
hero_aibroker, hero_food_server, hero_browser, hero_collab, gov_zdfz, hero_indexer, hero_runner, hero_office, hero_proxy, hero_archipelagos no .oschema n/a not applicable

Updated scope

  • Backfill build.rs to hero_whiteboard (per-repo PR).
  • Backfill build.rs to hero_fossil (per-repo PR).
  • Document the build.rs pattern in the hero_osis_guide skill so new services pick it up by default.
  • Operational: when a developer edits .oschema, they need to restart the running service for rpc.discover to advertise the new methods. The build.rs ensures the binary embeds the right spec, but cargo build alone does not redeploy a running service. Worth a one-liner in the skill.
  • Once both consumer crates have build.rs, revisit hero_rpc#40's per-request recompute. The recompute is a defensive measure; with build-time regen universally adopted, it can be reverted to a startup snapshot. (Optional — the recompute costs microseconds, so the revert is cosmetic, not load-driven.)

What this issue is NOT

  • It is not about adding a new feature to the generator. The feature exists.
  • It is not about hero_rpc#40 being wrong. That PR's runtime fix is independent and lands on its own merits (no in-memory cache layer between code and rpc.discover).

Closing the original "needs major work" framing — refiling as the four checkboxes above. Will pick up the two backfill PRs immediately.

## Audit results (downscoped) Verified the proposed pattern already works end-to-end: - `OschemaBuilder::generate()` (called from a service crate's `build.rs`) writes the per-domain `openrpc.json` via `Generator::generate_domain_files` (`crates/generator/src/generate.rs:404-411`). - `cargo:rerun-if-changed=...` is emitted for the schemas dir + each `.oschema` file (`crates/generator/src/build/build.rs:926, 931`). - Verified live: `touch crates/hero_logic/schemas/logic/logic.oschema && cargo build -p hero_logic` regenerates `src/logic/core/openrpc.json`. `include_str!` then captures the new content on the next compile. So the *infrastructure* for build-time regen is already in place. The issue was misdiagnosed as "missing feature" — it's "incomplete adoption." ## Audit of consumer crates | Crate | `.oschema`? | `build.rs`? | Status | |---|---|---|---| | hero_logic | yes | yes | ✓ | | hero_osis | yes | yes | ✓ | | hero_compute_manager | yes | yes | ✓ | | **hero_whiteboard** | yes (3 schemas) | **no** | needs backfill | | **hero_fossil** | yes (1 schema) | **no** | needs backfill | | hero_aibroker, hero_food_server, hero_browser, hero_collab, gov_zdfz, hero_indexer, hero_runner, hero_office, hero_proxy, hero_archipelagos | no `.oschema` | n/a | not applicable | ## Updated scope - [ ] Backfill `build.rs` to **hero_whiteboard** (per-repo PR). - [ ] Backfill `build.rs` to **hero_fossil** (per-repo PR). - [ ] Document the build.rs pattern in the `hero_osis_guide` skill so new services pick it up by default. - [ ] Operational: when a developer edits `.oschema`, they need to restart the running service for `rpc.discover` to advertise the new methods. The build.rs ensures the binary embeds the right spec, but `cargo build` alone does not redeploy a running service. Worth a one-liner in the skill. - [ ] Once both consumer crates have build.rs, revisit hero_rpc#40's per-request recompute. The recompute is a defensive measure; with build-time regen universally adopted, it can be reverted to a startup snapshot. (Optional — the recompute costs microseconds, so the revert is cosmetic, not load-driven.) ## What this issue is NOT - It is **not** about adding a new feature to the generator. The feature exists. - It is **not** about hero_rpc#40 being wrong. That PR's runtime fix is independent and lands on its own merits (no in-memory cache layer between code and `rpc.discover`). Closing the original "needs major work" framing — refiling as the four checkboxes above. Will pick up the two backfill PRs immediately.
timur commented 2026-05-05 11:29:36 +00:00
Author
Owner
Copy link

Audit results (downscoped)

Verified the proposed pattern already works end-to-end:

  • OschemaBuilder::generate() (called from a service crate's build.rs) writes the per-domain openrpc.json via Generator::generate_domain_files (crates/generator/src/generate.rs:404-411).
  • cargo:rerun-if-changed=... is emitted for the schemas dir + each .oschema file (crates/generator/src/build/build.rs:926, 931).
  • Verified live: touch crates/hero_logic/schemas/logic/logic.oschema && cargo build -p hero_logic regenerates src/logic/core/openrpc.json. include_str! then captures the new content on the next compile.

So the infrastructure for build-time regen is already in place. The issue was misdiagnosed as "missing feature" — it's "incomplete adoption."

Audit of consumer crates

Crate .oschema? build.rs? Status
hero_logic yes yes ✓
hero_osis yes yes ✓
hero_compute_manager yes yes ✓
hero_whiteboard yes (3 schemas) no needs backfill
hero_fossil yes (1 schema) no needs backfill
hero_aibroker, hero_food_server, hero_browser, hero_collab, gov_zdfz, hero_indexer, hero_runner, hero_office, hero_proxy, hero_archipelagos no .oschema n/a not applicable

Updated scope

  • Backfill build.rs to hero_whiteboard (per-repo PR).
  • Backfill build.rs to hero_fossil (per-repo PR).
  • Document the build.rs pattern in the hero_osis_guide skill so new services pick it up by default.
  • Operational: when a developer edits .oschema, they need to restart the running service for rpc.discover to advertise the new methods. The build.rs ensures the binary embeds the right spec, but cargo build alone does not redeploy a running service. Worth a one-liner in the skill.
  • Once both consumer crates have build.rs, revisit hero_rpc#40's per-request recompute. The recompute is a defensive measure; with build-time regen universally adopted, it can be reverted to a startup snapshot. (Optional — the recompute costs microseconds, so the revert is cosmetic, not load-driven.)

What this issue is NOT

  • It is not about adding a new feature to the generator. The feature exists.
  • It is not about hero_rpc#40 being wrong. That PR's runtime fix is independent and lands on its own merits (no in-memory cache layer between code and rpc.discover).

Closing the original "needs major work" framing — refiling as the four checkboxes above. Will pick up the two backfill PRs immediately.

## Audit results (downscoped) Verified the proposed pattern already works end-to-end: - `OschemaBuilder::generate()` (called from a service crate's `build.rs`) writes the per-domain `openrpc.json` via `Generator::generate_domain_files` (`crates/generator/src/generate.rs:404-411`). - `cargo:rerun-if-changed=...` is emitted for the schemas dir + each `.oschema` file (`crates/generator/src/build/build.rs:926, 931`). - Verified live: `touch crates/hero_logic/schemas/logic/logic.oschema && cargo build -p hero_logic` regenerates `src/logic/core/openrpc.json`. `include_str!` then captures the new content on the next compile. So the *infrastructure* for build-time regen is already in place. The issue was misdiagnosed as "missing feature" — it's "incomplete adoption." ## Audit of consumer crates | Crate | `.oschema`? | `build.rs`? | Status | |---|---|---|---| | hero_logic | yes | yes | ✓ | | hero_osis | yes | yes | ✓ | | hero_compute_manager | yes | yes | ✓ | | **hero_whiteboard** | yes (3 schemas) | **no** | needs backfill | | **hero_fossil** | yes (1 schema) | **no** | needs backfill | | hero_aibroker, hero_food_server, hero_browser, hero_collab, gov_zdfz, hero_indexer, hero_runner, hero_office, hero_proxy, hero_archipelagos | no `.oschema` | n/a | not applicable | ## Updated scope - [ ] Backfill `build.rs` to **hero_whiteboard** (per-repo PR). - [ ] Backfill `build.rs` to **hero_fossil** (per-repo PR). - [ ] Document the build.rs pattern in the `hero_osis_guide` skill so new services pick it up by default. - [ ] Operational: when a developer edits `.oschema`, they need to restart the running service for `rpc.discover` to advertise the new methods. The build.rs ensures the binary embeds the right spec, but `cargo build` alone does not redeploy a running service. Worth a one-liner in the skill. - [ ] Once both consumer crates have build.rs, revisit hero_rpc#40's per-request recompute. The recompute is a defensive measure; with build-time regen universally adopted, it can be reverted to a startup snapshot. (Optional — the recompute costs microseconds, so the revert is cosmetic, not load-driven.) ## What this issue is NOT - It is **not** about adding a new feature to the generator. The feature exists. - It is **not** about hero_rpc#40 being wrong. That PR's runtime fix is independent and lands on its own merits (no in-memory cache layer between code and `rpc.discover`). Closing the original "needs major work" framing — refiling as the four checkboxes above. Will pick up the two backfill PRs immediately.
timur commented 2026-05-05 11:32:01 +00:00
Author
Owner
Copy link

Closing — full audit results above. Net work delta:

  • ✓ build-time regen infrastructure exists in OschemaBuilder::generate() and is wired correctly.
  • ✓ All OSIS-server-pattern consumer crates (hero_logic, hero_osis, hero_compute_manager) already have build.rs.
  • ✗ The two crates without build.rs (hero_whiteboard, hero_fossil) don't use the OSIS-server pattern — they have hand-written openrpc.json files. That's a different drift class (hand-written vs schema-derived) and out of scope here.
  • ✓ Documented the operational follow-through ("restart after rebuild") in the hero_osis_guide skill so the next person debugging stale rpc.discover reaches the right answer faster.

hero_rpc#40's per-request recompute stays in place — it's microseconds of cost and provides defense-in-depth against future cache-coherence regressions. Not worth a revert.

No follow-up PRs needed.

Closing — full audit results above. Net work delta: - ✓ build-time regen infrastructure exists in `OschemaBuilder::generate()` and is wired correctly. - ✓ All OSIS-server-pattern consumer crates (hero_logic, hero_osis, hero_compute_manager) already have `build.rs`. - ✗ The two crates without `build.rs` (hero_whiteboard, hero_fossil) **don't use the OSIS-server pattern** — they have hand-written `openrpc.json` files. That's a different drift class (hand-written vs schema-derived) and out of scope here. - ✓ Documented the operational follow-through ("restart after rebuild") in the `hero_osis_guide` skill so the next person debugging stale `rpc.discover` reaches the right answer faster. hero_rpc#40's per-request recompute stays in place — it's microseconds of cost and provides defense-in-depth against future cache-coherence regressions. Not worth a revert. No follow-up PRs needed.
timur closed this issue 2026-05-05 11:32:02 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
issue-60-method-translators
issue-54-scaffold-extend
issue-55-codegen-alignment
development_refactor_list_full
fix/input-schema-and-find
main
development_jan
v0.1.0
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
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_rpc#41
No description provided.