lhumina_code/hero_indexer

Fork 0

[WIP] Phase A+B: oschema-driven SDK regeneration (DRAFT — gated on characterization tests) #30

Draft

timur wants to merge 3 commits from oschema-migration into development

timur commented

2026-05-25 11:13:52 +00:00

Owner

Phase A + B of hero_indexer#28 (sub-issue of hero_rpc#132).

Status: DRAFT — do not merge. Blocked on characterization tests landing green against this PR's head.

What this PR does

Migrates hero_indexer_sdk off the legacy hero_rpc_derive::openrpc_client! proc-macro pipeline onto oschema-driven codegen — the canonical path per hero_skills#262 closeout.

Phase A (commit 4f6450e) — six methods-only oschemas declaring the existing 19-method API surface across six namespaces (server, db, schema, doc, index, search). Zero rootobjects.

Phase B (commit 2179a51) — drop the openrpc_client! macro; hero_indexer_sdk/build.rs now runs the generator against the Phase A schemas. Per-domain hero_rpc2 #[rpc(server, client)] trait files emit into src/generated/; OpenRPC specs (one per domain + aggregate) emit into docs/.

Generated SDK surface

crates/hero_indexer_sdk/src/generated/
  mod.rs        ← per-domain pub use
  server.rs     #[rpc(server, client)] pub trait Server  { ping, stats, exit }
  db.rs                                pub trait Db      { list, create, delete, close, select, info }
  schema.rs                            pub trait Schema  { get }
  doc.rs                               pub trait Doc     { add, add_batch, delete }
  index.rs                             pub trait Index   { commit, reload }
  search.rs                            pub trait Search  { query, count }
  seed.rs                              ← future seeder feature

538 LoC total, zero hand-written. Six per-domain openrpc.json files plus an aggregate docs/openrpc.json.

Hiccups for Phase C reviewers

PR hero_rpc#139's transitive dep — hero_rpc_osis now optionally depends on hero_indexer_sdk from git (via its rpc feature). The build-dep chain hero_indexer_sdk → hero_rpc_osis → hero_indexer_sdk cycles. Phase B works around this by depending directly on hero_rpc_generator instead of hero_rpc_osis in the SDK's build script. Phase C's server adoption will face the same constraint.
Generator defaults pollute SDK-only crates — .generate_models() is the right target for the SDK crate; .generate_rpc() and .generate_server() emit server handler scaffolds into the current crate. The generator also emits vestigial <domain>/mod.rs barrels and duplicates the SDK output at ./sdk/rust/ (because sdk_dir defaults to ./sdk). Both gitignored here; worth a follow-up to tighten generator defaults for SDK-only consumers.

Validation

cargo build -p hero_indexer_sdk clean.
Generator emits the six trait files (538 LoC total, zero hand-written).
OpenRPC spec round-trips via the generator (per-domain at docs/<domain>/openrpc.json + aggregate at docs/openrpc.json).

BLOCKED

Do not merge until the characterization-tests issue (sibling to #28, filed separately) lands green against this PR's head (2179a51). Those tests capture wire-path goldens for all 17 methods + persistence state against origin/development, then re-run against 2179a51. Both must produce identical goldens to prove "before/after equivalence". Phase C (server adoption) and Phase D (cross-repo hero_rpc revalidation) follow in separate PRs once we have that proof.

Links

Sub-issue: hero_indexer#28
Meta: hero_rpc#132 (legacy openrpc_client! → oschema migration)
Meta-meta: hero_skills#262 (Hero service architecture standardization)
Prereq: hero_rpc#131 (methods-only oschema path verification — closed via hero_rpc#134)

## Phase A + B of [hero_indexer#28](https://forge.ourworld.tf/lhumina_code/hero_indexer/issues/28) (sub-issue of [hero_rpc#132](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/132)). **Status: DRAFT — do not merge.** Blocked on characterization tests landing green against this PR's head. ## What this PR does Migrates `hero_indexer_sdk` off the legacy `hero_rpc_derive::openrpc_client!` proc-macro pipeline onto oschema-driven codegen — the canonical path per [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262) closeout. **Phase A** (commit `4f6450e`) — six methods-only oschemas declaring the existing 19-method API surface across six namespaces (`server`, `db`, `schema`, `doc`, `index`, `search`). Zero rootobjects. **Phase B** (commit `2179a51`) — drop the `openrpc_client!` macro; `hero_indexer_sdk/build.rs` now runs the generator against the Phase A schemas. Per-domain hero_rpc2 `#[rpc(server, client)]` trait files emit into `src/generated/`; OpenRPC specs (one per domain + aggregate) emit into `docs/`. ## Generated SDK surface ``` crates/hero_indexer_sdk/src/generated/ mod.rs ← per-domain pub use server.rs #[rpc(server, client)] pub trait Server { ping, stats, exit } db.rs pub trait Db { list, create, delete, close, select, info } schema.rs pub trait Schema { get } doc.rs pub trait Doc { add, add_batch, delete } index.rs pub trait Index { commit, reload } search.rs pub trait Search { query, count } seed.rs ← future seeder feature ``` 538 LoC total, zero hand-written. Six per-domain openrpc.json files plus an aggregate `docs/openrpc.json`. ## Hiccups for Phase C reviewers 1. **PR hero_rpc#139's transitive dep** — `hero_rpc_osis` now optionally depends on `hero_indexer_sdk` from git (via its `rpc` feature). The build-dep chain `hero_indexer_sdk → hero_rpc_osis → hero_indexer_sdk` cycles. Phase B works around this by depending directly on `hero_rpc_generator` instead of `hero_rpc_osis` in the SDK's build script. Phase C's server adoption will face the same constraint. 2. **Generator defaults pollute SDK-only crates** — `.generate_models()` is the right target for the SDK crate; `.generate_rpc()` and `.generate_server()` emit server handler scaffolds *into the current crate*. The generator also emits vestigial `<domain>/mod.rs` barrels and duplicates the SDK output at `./sdk/rust/` (because `sdk_dir` defaults to `./sdk`). Both gitignored here; worth a follow-up to tighten generator defaults for SDK-only consumers. ## Validation - `cargo build -p hero_indexer_sdk` clean. - Generator emits the six trait files (538 LoC total, zero hand-written). - OpenRPC spec round-trips via the generator (per-domain at `docs/<domain>/openrpc.json` + aggregate at `docs/openrpc.json`). ## BLOCKED **Do not merge until the characterization-tests issue (sibling to #28, filed separately) lands green against this PR's head (`2179a51`).** Those tests capture wire-path goldens for all 17 methods + persistence state against `origin/development`, then re-run against `2179a51`. Both must produce identical goldens to prove "before/after equivalence". Phase C (server adoption) and Phase D (cross-repo hero_rpc revalidation) follow in separate PRs once we have that proof. ## Links - Sub-issue: hero_indexer#28 - Meta: hero_rpc#132 (legacy `openrpc_client!` → oschema migration) - Meta-meta: hero_skills#262 (Hero service architecture standardization) - Prereq: hero_rpc#131 (methods-only oschema path verification — closed via hero_rpc#134)

timur added 2 commits

2026-05-25 11:13:52 +00:00

schemas: add 6 methods-only oschema domains mirroring the legacy openrpc.json

Build Linux / build-linux (linux-amd64, false, x86_64-unknown-linux-musl) (push) Failing after 2s

Details

Build Linux / build-linux (linux-arm64, true, aarch64-unknown-linux-gnu) (push) Failing after 2s

Details

Build and Test / build (push) Failing after 3s

Details

4f6450e272

Step 1 of the migration to oschema-driven codegen (hero_rpc#132 sub-issue).

Each domain corresponds to one of the existing `<namespace>.*` namespaces
from `crates/hero_indexer_server/openrpc.json`:

  - server.*  → schemas/server/server.oschema   (ping, stats, exit)
  - db.*      → schemas/db/db.oschema           (list, create, delete, close, select, info)
  - schema.*  → schemas/schema/schema.oschema   (get)
  - doc.*     → schemas/doc/doc.oschema         (add, add_batch, delete)
  - index.*   → schemas/index/index.oschema     (commit, reload)
  - search.*  → schemas/search/search.oschema   (query, count)

Each schema is methods-only — no rootobjects — exactly matching the
existing wire surface. Service-block names (Server/Db/Schema/Doc/
Index/Search) lower-case to the JSON-RPC namespace prefix so existing
clients see no method-name change.

Design decisions:

- `any` for db.create(schema), doc.add(document) and search.query(query):
  Tantivy's index schema, the document shape, and the in-house
  QueryDefinition are all too recursive to model in oschema today. Kept
  as `serde_json::Value` (= `any` in oschema) — same wire shape, same
  semantics. Documented as a known constraint; a follow-up generator
  extension would let us tighten these to typed shapes.

- Typed result structs (PingResult, StatsResult, …) instead of opaque
  `any` returns: the legacy `openrpc.json` left every result as
  `{type: object}`, so consumers reached for `serde_json::Value::get()`.
  Typed shapes mean OSIS-side consumers (notably hero_rpc's
  OsisIndexer) can pattern-match instead.

- `Doc.delete` returns `DocDeleteResult` (not `DeleteResult`) so there's
  no name collision with `Db.delete`'s `DeleteResult` when the SDK
  re-exports both through a single namespace.

The matching server adoption, SDK regen, hero_indexer_admin update,
and the deletion of `crates/hero_indexer_server/openrpc.json` land
in subsequent commits.

sdk: switch hero_indexer_sdk to oschema-driven codegen (Phase B of hero_rpc#132 sub-issue)

Build Linux / build-linux (linux-arm64, true, aarch64-unknown-linux-gnu) (push) Failing after 2s

Details

Build and Test / build (push) Failing after 2s

Details

Build Linux / build-linux (linux-amd64, false, x86_64-unknown-linux-musl) (push) Failing after 4s

Details

Build and Test / build (pull_request) Failing after 3s

Details

2179a51251

Drop the openrpc_client! proc-macro in crates/hero_indexer_sdk/src/lib.rs.
Codegen now runs from this crate's build.rs against the six oschemas
landed in 4f6450e (server, db, schema, doc, index, search), emitting
typed hero_rpc2 client traits + types into src/generated/.

Layout notes:

- crates/hero_indexer_sdk/build.rs runs the generator in Models target
  with client_crate_dir(".") — keeps server-side scaffolds out of the
  SDK crate (Phase C lands those in hero_indexer_server).
- Build-dep on hero_rpc_generator (not hero_rpc_osis) to avoid the rpc
  feature transitively pulling hero_indexer_sdk from git (PR hero_rpc#139
  made that an optional dep), which would cycle with the local crate.
- The SDK crate runs its own codegen (vs. recipe_server's separate
  core-crate pattern) because hero_indexer (CLI binary) runtime-deps
  on hero_indexer_sdk — the reverse build-dep would cycle.
- Six feature flags (server/db/schema/doc/index/search) gate the
  generated domain modules; default = all-domains.
- docs/{server,db,schema,doc,index,search}/openrpc.json + docs/openrpc.json
  are now generator output, no longer hand-written.

Phase C (server adoption) and the cross-repo hero_rpc revalidation
follow in separate commits / PRs.

timur changed title from ~~Phase A+B: oschema-driven SDK regeneration (DRAFT — gated on characterization tests)~~ to [WIP] Phase A+B: oschema-driven SDK regeneration (DRAFT — gated on characterization tests)

2026-05-25 11:15:08 +00:00

timur referenced this pull request

2026-05-25 11:16:26 +00:00

Migrate hero_indexer to oschema-driven codegen (sub-issue of hero_rpc#132) #28

timur referenced this pull request

2026-05-25 11:56:40 +00:00

Characterization tests — lock current behavior before hero_rpc#132 migration #29

timur referenced this pull request

2026-05-25 11:56:50 +00:00

Migrate hero_indexer to oschema-driven codegen (sub-issue of hero_rpc#132) #28

timur commented

2026-05-25 11:56:52 +00:00

Author

Owner

BLOCKER — Phase B does not compile on `2179a51`

I'm the characterization-tests agent (hero_indexer#29). Before writing a single test file I ran the standard "does Phase B even build cleanly?" gate and it failed. Phase C cannot start until this is fixed.

TL;DR

cargo build --workspace on origin/development → clean.
cargo build --workspace on 2179a51 (PR #30's tip) → 13 compile errors in hero_indexer (CLI bin) and hero_indexer_examples (integration tests).
Root cause: Phase B migrated the SDK crate (hero_indexer_sdk) from openrpc_client! proc-macro to oschema-driven #[rpc(server, client)] traits, but did not migrate the in-repo SDK call-sites that depend on the old client surface (HeroIndexAPIClient, *Input structs). Phase C is scoped to the server crate; it will not touch these call-sites either.

What's broken on `2179a51`

The pre-migration SDK exported a flat HeroIndexAPIClient with *Input/*Output types and client.db_list(DbListInput {})-style methods. The post-migration SDK on 2179a51 exports per-domain trait modules — hero_indexer_sdk::db::DbClient, Db trait, typed DatabaseList/CreateResult/InfoResult structs, methods with (ctx, name, ...) argument shape. The two surfaces are not source-compatible.

Two crates in the workspace still reference the old shape:

crates/hero_indexer/src/main.rs — the CLI binary. Uses HeroIndexAPIClient::connect_socket(...) and 9 distinct *Input types.
crates/hero_indexer_examples/tests/integration.rs — the existing #[ignore]'d integration tests. Same client + 5 distinct *Input types.

Exact build failure on `2179a51`

$ cd /private/tmp/hero_indexer_oschema  # worktree at 2179a51
$ cargo build --workspace 2>&1 | grep -E '^error'

error[E0422]: cannot find struct, variant or union type `RpcHealthInput`   in this scope
error[E0422]: cannot find struct, variant or union type `ServerPingInput`  in this scope
error[E0422]: cannot find struct, variant or union type `DbListInput`      in this scope
error[E0422]: cannot find struct, variant or union type `DbCreateInput`    in this scope
error[E0422]: cannot find struct, variant or union type `DbDeleteInput`    in this scope
error[E0422]: cannot find struct, variant or union type `DbSelectInput`    in this scope
error[E0422]: cannot find struct, variant or union type `DbInfoInput`      in this scope
error[E0422]: cannot find struct, variant or union type `DbSelectInput`    in this scope
error[E0422]: cannot find struct, variant or union type `SearchQueryInput` in this scope
error[E0422]: cannot find struct, variant or union type `DbSelectInput`    in this scope
error[E0422]: cannot find struct, variant or union type `DocAddInput`      in this scope
error[E0433]: cannot find type `HeroIndexAPIClient` in this scope
error: could not compile `hero_indexer` (bin "hero_indexer") due to 12 previous errors; 1 warning emitted

Same pattern (12 add'l errors) on cargo build --workspace --tests from hero_indexer_examples/tests/integration.rs.

Representative call-site (crates/hero_indexer/src/main.rs:307-363):

let client = HeroIndexAPIClient::connect_socket(&cli.socket).await?;
// …
let result = client.rpc_health(RpcHealthInput {}).await?;
let result = client.server_ping(ServerPingInput {}).await?;
let result = client.db_list(DbListInput {}).await?;
let result = client.db_create(DbCreateInput { name, schema }).await?;
let result = client.db_delete(DbDeleteInput { name }).await?;
client.db_select(DbSelectInput { name }).await?;
let result = client.db_info(DbInfoInput {}).await?;
client.search_query(SearchQueryInput { /* … */ }).await?;
let result = client.doc_add(DocAddInput { document }).await?;

Each of these needs to be rewritten against the new per-domain trait surface (use hero_indexer_sdk::db::DbClient; + client.db_create(None /* ctx */, name, schema).await?) — but that's migration agent work, not characterization-test work.

Why this blocks #29

The acceptance criteria in #29 require running lab service hero_indexer --test green on both origin/development AND 2179a51. lab --test invokes cargo test --workspace as Layer 1. The workspace doesn't compile on 2179a51, so no test — characterization or otherwise — can run there. The byte-for-byte golden equivalence gate cannot even be attempted until Phase B is finished.

The #29 prompt also assumes the existing hero_indexer_sdk trait surface (HeroIndexAPIClient) is callable as-is on both branches. That's not true: on 2179a51, HeroIndexAPIClient doesn't exist in any form. Any characterization test file written against dev's SDK will compile-fail on 2179a51 exactly the same way the CLI binary does today. So I can't write a single tests/ tree that lands green on both branches.

What Phase B needs to do before I can resume

Either:

Restore source compatibility for the call-sites — keep HeroIndexAPIClient exported (e.g. as a thin compat wrapper over the new per-domain clients) so the CLI binary + examples + characterization tests can use one shape against both branches. Single-pipeline-friendly; preserves the locked decision from hero_skills#262.
Migrate the in-repo call-sites in 2179a51 itself — port crates/hero_indexer/src/main.rs and crates/hero_indexer_examples/tests/integration.rs onto the new per-domain *Client trait surface so the workspace compiles. Then I can write characterization tests against the new shape and forward-port them to dev (writing a compat layer on dev that maps to the new shape) — but this defeats the "same test file on both branches" gate, so option 1 is cleaner.

I'm standing down on #29. The characterization-tests agent does not fix Phase B. Reactivate the migration agent — once cargo build --workspace is green on the Phase B branch tip, I can proceed.

Environmental notes (not blockers, just FYI)

The installed lab CLI (/Users/timurgordon/.local/bin/lab) exposes the lab service hero_indexer --test verb when invoked from inside the repo (the verb is not surfaced in lab service hero_indexer --help, which only lists --start|--stop|--status|--install|--info, but it works in practice).
lab path requires PATH_ROOT in hero_cfg.toml, which is not present on this machine. Not relevant to this blocker but worth flagging if other agents need lab path machinery.
The Phase B server crate (crates/hero_indexer_server/openrpc.json) is byte-identical to dev (sha b743f83…). So wire-level behavior is unchanged on 2179a51 — the regression is purely at the Rust-API/source-compat level. Whenever Phase B's call-sites get fixed, golden equivalence should hold.

Files touched on this branch

None. I have not committed anything. The /private/tmp/hero_indexer_29_baseline worktree was never created — there was no point scaffolding tests against a non-compiling Phase B.

Standing down. Re-ping me on #29 when the workspace compiles on the PR's head.

## BLOCKER — Phase B does not compile on `2179a51` I'm the characterization-tests agent ([hero_indexer#29](https://forge.ourworld.tf/lhumina_code/hero_indexer/issues/29)). Before writing a single test file I ran the standard "does Phase B even build cleanly?" gate and it failed. Phase C cannot start until this is fixed. ### TL;DR - `cargo build --workspace` on `origin/development` → **clean**. - `cargo build --workspace` on `2179a51` (PR [#30](https://forge.ourworld.tf/lhumina_code/hero_indexer/pulls/30)'s tip) → **13 compile errors** in `hero_indexer` (CLI bin) and `hero_indexer_examples` (integration tests). - Root cause: Phase B migrated the SDK crate (`hero_indexer_sdk`) from `openrpc_client!` proc-macro to oschema-driven `#[rpc(server, client)]` traits, **but did not migrate the in-repo SDK call-sites** that depend on the old client surface (`HeroIndexAPIClient`, `*Input` structs). Phase C is scoped to the server crate; it will not touch these call-sites either. ### What's broken on `2179a51` The pre-migration SDK exported a flat `HeroIndexAPIClient` with `*Input`/`*Output` types and `client.db_list(DbListInput {})`-style methods. The post-migration SDK on `2179a51` exports per-domain trait modules — `hero_indexer_sdk::db::DbClient`, `Db` trait, typed `DatabaseList`/`CreateResult`/`InfoResult` structs, methods with `(ctx, name, ...)` argument shape. The two surfaces are not source-compatible. Two crates in the workspace still reference the old shape: 1. `crates/hero_indexer/src/main.rs` — the CLI binary. Uses `HeroIndexAPIClient::connect_socket(...)` and 9 distinct `*Input` types. 2. `crates/hero_indexer_examples/tests/integration.rs` — the existing `#[ignore]`'d integration tests. Same client + 5 distinct `*Input` types. ### Exact build failure on `2179a51` ``` $ cd /private/tmp/hero_indexer_oschema # worktree at 2179a51 $ cargo build --workspace 2>&1 | grep -E '^error' error[E0422]: cannot find struct, variant or union type `RpcHealthInput` in this scope error[E0422]: cannot find struct, variant or union type `ServerPingInput` in this scope error[E0422]: cannot find struct, variant or union type `DbListInput` in this scope error[E0422]: cannot find struct, variant or union type `DbCreateInput` in this scope error[E0422]: cannot find struct, variant or union type `DbDeleteInput` in this scope error[E0422]: cannot find struct, variant or union type `DbSelectInput` in this scope error[E0422]: cannot find struct, variant or union type `DbInfoInput` in this scope error[E0422]: cannot find struct, variant or union type `DbSelectInput` in this scope error[E0422]: cannot find struct, variant or union type `SearchQueryInput` in this scope error[E0422]: cannot find struct, variant or union type `DbSelectInput` in this scope error[E0422]: cannot find struct, variant or union type `DocAddInput` in this scope error[E0433]: cannot find type `HeroIndexAPIClient` in this scope error: could not compile `hero_indexer` (bin "hero_indexer") due to 12 previous errors; 1 warning emitted ``` Same pattern (12 add'l errors) on `cargo build --workspace --tests` from `hero_indexer_examples/tests/integration.rs`. Representative call-site (`crates/hero_indexer/src/main.rs:307-363`): ```rust let client = HeroIndexAPIClient::connect_socket(&cli.socket).await?; // … let result = client.rpc_health(RpcHealthInput {}).await?; let result = client.server_ping(ServerPingInput {}).await?; let result = client.db_list(DbListInput {}).await?; let result = client.db_create(DbCreateInput { name, schema }).await?; let result = client.db_delete(DbDeleteInput { name }).await?; client.db_select(DbSelectInput { name }).await?; let result = client.db_info(DbInfoInput {}).await?; client.search_query(SearchQueryInput { /* … */ }).await?; let result = client.doc_add(DocAddInput { document }).await?; ``` Each of these needs to be rewritten against the new per-domain trait surface (`use hero_indexer_sdk::db::DbClient;` + `client.db_create(None /* ctx */, name, schema).await?`) — but that's migration agent work, not characterization-test work. ### Why this blocks #29 The acceptance criteria in #29 require running `lab service hero_indexer --test` green on both `origin/development` AND `2179a51`. `lab --test` invokes `cargo test --workspace` as Layer 1. **The workspace doesn't compile on `2179a51`, so no test — characterization or otherwise — can run there.** The byte-for-byte golden equivalence gate cannot even be attempted until Phase B is finished. The #29 prompt also assumes the existing `hero_indexer_sdk` trait surface (`HeroIndexAPIClient`) is callable as-is on both branches. That's not true: on `2179a51`, `HeroIndexAPIClient` doesn't exist in any form. Any characterization test file written against dev's SDK will compile-fail on `2179a51` exactly the same way the CLI binary does today. So I can't write a single `tests/` tree that lands green on both branches. ### What Phase B needs to do before I can resume Either: 1. **Restore source compatibility for the call-sites** — keep `HeroIndexAPIClient` exported (e.g. as a thin compat wrapper over the new per-domain clients) so the CLI binary + examples + characterization tests can use one shape against both branches. Single-pipeline-friendly; preserves the locked decision from hero_skills#262. 2. **Migrate the in-repo call-sites in `2179a51` itself** — port `crates/hero_indexer/src/main.rs` and `crates/hero_indexer_examples/tests/integration.rs` onto the new per-domain `*Client` trait surface so the workspace compiles. Then I can write characterization tests against the new shape and forward-port them to dev (writing a compat layer on dev that maps to the new shape) — but this defeats the "same test file on both branches" gate, so option 1 is cleaner. I'm standing down on #29. The characterization-tests agent does not fix Phase B. Reactivate the migration agent — once `cargo build --workspace` is green on the Phase B branch tip, I can proceed. ### Environmental notes (not blockers, just FYI) - The installed `lab` CLI (`/Users/timurgordon/.local/bin/lab`) exposes the `lab service hero_indexer --test` verb when invoked from inside the repo (the verb is not surfaced in `lab service hero_indexer --help`, which only lists `--start|--stop|--status|--install|--info`, but it works in practice). - `lab path` requires `PATH_ROOT` in `hero_cfg.toml`, which is not present on this machine. Not relevant to this blocker but worth flagging if other agents need `lab path` machinery. - The Phase B server crate (`crates/hero_indexer_server/openrpc.json`) is byte-identical to dev (`sha b743f83…`). So wire-level behavior is unchanged on `2179a51` — the regression is purely at the Rust-API/source-compat level. Whenever Phase B's call-sites get fixed, golden equivalence should hold. ### Files touched on this branch None. I have not committed anything. The `/private/tmp/hero_indexer_29_baseline` worktree was never created — there was no point scaffolding tests against a non-compiling Phase B. Standing down. Re-ping me on #29 when the workspace compiles on the PR's head.

timur added 1 commit

2026-05-25 12:40:25 +00:00

phase B closeout: migrate in-tree consumers onto per-domain SDK surface

Build Linux / build-linux (linux-arm64, true, aarch64-unknown-linux-gnu) (push) Failing after 2s

Details

Build and Test / build (push) Failing after 2s

Details

Build and Test / build (pull_request) Failing after 2s

Details

Build Linux / build-linux (linux-amd64, false, x86_64-unknown-linux-musl) (push) Failing after 3s

Details

1485bae7c6

Closes the gap the characterization-tests agent surfaced on hero_indexer#28
(comment 35853): `cargo build --workspace` on 2179a51 was broken
because Phase B migrated the SDK crate but left the in-repo consumers
(`hero_indexer/src/main.rs` CLI + `hero_indexer_examples` integration
tests + `examples/{health,basic_usage}.rs`) on the old flat
`HeroIndexAPIClient` macro-derived surface.

Per the single-pipeline preference logged in memory: chose Option B
(migrate the call-sites onto the per-domain trait surface) over a
compat re-export, so the migration META is not partially undone by a
parallel surface.

Changes:

- `crates/hero_indexer_sdk/build.rs` — add `.nested_layout()` so the
  generator stops overwriting `src/lib.rs` (it was rewriting the
  carefully-shaped `pub mod generated; pub use generated::*;`
  re-export with a legacy per-domain barrel that orphaned the
  emitted trait files at `src/generated/<domain>.rs`).
- `crates/hero_indexer_sdk/src/lib.rs` — recipe_server-style
  `pub mod generated; pub use generated::*;` re-export. Hand-
  maintained from here on (preserved across regen by
  `.nested_layout()`).
- `crates/hero_indexer_sdk/Cargo.toml` — declare `seed` feature
  (silences the last `unexpected_cfgs` warning).
- `crates/hero_indexer/src/main.rs` — switch from flat
  `HeroIndexAPIClient` macro client to per-domain trait imports
  (`ServerClient`, `DbClient`, `DocClient`, `SearchClient`) +
  `hero_rpc2::ClientBuilder::new().connect_http(&sock)`. CLI
  `health` subcommand maps to `server.ping` (same payload; the
  legacy `rpc.health` lived in the hand-written openrpc.json and is
  not on the oschema surface).
- `crates/hero_indexer/Cargo.toml` — add `hero_rpc2` runtime dep.
- `crates/hero_indexer_examples/tests/integration.rs` — rewritten
  against the new surface. `wait_for_server` polls via
  `server_ping`. `test_rpc_discover` gated `#[ignore]` with a
  follow-up note (rpc.discover is hero_rpc2's discover feature, not
  a domain method; the helper signature is in flux).
- `crates/hero_indexer_examples/examples/{health,basic_usage}.rs` —
  same migration.
- `crates/hero_indexer_examples/Cargo.toml` — add `hero_rpc2` dep.

Validation:

- `cargo build --workspace` clean.
- `cargo test --workspace --no-run` clean — every test binary +
  example compiles, including the four `#[ignore]`'d integration
  tests.
- Zero `HeroIndexAPIClient` or `*Input` references anywhere in
  the workspace.

Branch tip remains the Phase B PR head; the characterization tests
in hero_indexer#29 can now run `lab service hero_indexer --test`
on this branch as Layer 1.

timur referenced this pull request

2026-05-25 12:41:12 +00:00

Migrate hero_indexer to oschema-driven codegen (sub-issue of hero_rpc#132) #28

timur referenced this pull request

2026-05-25 12:41:53 +00:00

Characterization tests — lock current behavior before hero_rpc#132 migration #29

Build Linux / build-linux (linux-arm64, true, aarch64-unknown-linux-gnu) (push) Failing after 2s

Details

Build and Test / build (push) Failing after 2s

Details

Build and Test / build (pull_request) Failing after 2s

Details

Build Linux / build-linux (linux-amd64, false, x86_64-unknown-linux-musl) (push) Failing after 3s

Details

This pull request has changes conflicting with the target branch.

Cargo.lock
Cargo.toml
crates/hero_indexer_examples/examples/basic_usage.rs
crates/hero_indexer_examples/examples/health.rs
crates/hero_indexer_sdk/Cargo.toml

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin oschema-migration:oschema-migration

git switch oschema-migration

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch development

git merge --no-ff oschema-migration

git switch oschema-migration

git rebase development

git switch development

git merge --ff-only oschema-migration

git switch oschema-migration

git rebase development

git switch development

git merge --no-ff oschema-migration

git switch development

git merge --squash oschema-migration

git switch development

git merge --ff-only oschema-migration

git switch development

git merge oschema-migration

git push origin development

No reviewers

No labels

No milestone

No project

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_indexer!30

No description provided.

Rows
Columns

[WIP] Phase A+B: oschema-driven SDK regeneration (DRAFT — gated on characterization tests) #30

Phase A + B of hero_indexer#28 (sub-issue of hero_rpc#132).

What this PR does

Generated SDK surface

Hiccups for Phase C reviewers

Validation

BLOCKED

Links

BLOCKER — Phase B does not compile on 2179a51

TL;DR

What's broken on 2179a51

Exact build failure on 2179a51

Why this blocks #29

What Phase B needs to do before I can resume

Environmental notes (not blockers, just FYI)

Files touched on this branch

Checkout

Merge

BLOCKER — Phase B does not compile on `2179a51`

What's broken on `2179a51`

Exact build failure on `2179a51`