hero_voice no longer builds from source: SDK on the strict openrpc macro, spec and secret API not conformed #37
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_voice#37
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
hero_voice does not build from source on main or development right now, while the deployed release still runs fine in the sandbox, so this is about rebuilding, not a live outage.
The cause is that the SDK moved to the stricter openrpc client macro (herolib_openrpc), which rejects dot-namespaced method names and any method that takes more than one parameter. The spec in crates/hero_voice_server/openrpc.json still uses dot names and has 13 multi-param methods, and crates/hero_voice_admin still calls the old hero_proc_sdk secret API (secret_get / SecretGetInput) which no longer exists. The last commit whose CI built green is
a6b3e5178e(2026-05-28), which used the older lenient macro.Fixing forward without losing the work since then is your call on direction. Option A: conform the spec to the strict macro by giving each of these 13 methods a single struct input and dropping the dot prefix (create_topic, create_folder, rename_topic, rename_folder, move_topic, move_folder, save_content, transform_content, transform_text, synthesize_speech, transcribe, register_audio, delete_audio), plus migrate the admin to the new hero_proc_sdk secret API. Option B: revert the SDK back to the lenient macro and keep the recent features. Which one is right depends on the openrpc consolidation plan (hero_rpc into hero_blueprint plus herolib_openrpc), so it is yours.
Two more notes: main has a leftover merge conflict marker in Cargo.toml that needs resolving, and the CI publish rule was already aligned to publish the stable release from main, so a green main build will republish automatically. Happy to help once the macro direction is decided.
Signed-by: mik-tf mik-tf@noreply.invalid
Update: main is fixed, and the cause was confirmed with Scott to be an erroneous merge of development into main. That merge brought the development_refactor branch in with unresolved conflict markers across several files, so main stopped building.
Resolution: main was reset to the last building commit before that merge and Scott's VAD endpointing commit was cherry-picked on top, so main builds again (verified locally) and is rebuilding its release now. Nothing was lost: the development-origin commits (the herolib/openrpc migration, theme fetch, etc.) are all still on the development branch, and VAD is preserved on main via the cherry-pick.
What remains for the voice owner, separately and on your own timeline: when the openrpc consolidation settles, land the migration onto main intentionally (conform the spec to the strict client macro, meaning single-struct method inputs and no dot-namespaced method names, plus the updated hero_proc_sdk secret API). Until then main stays on the pre-migration build, which is fine for the sandbox.
Signed-by: mik-tf mik-tf@noreply.invalid
Main is green: the rebuilt voice release published from main (server + admin). The gnu workflow was also missing the private-dependency git credential step, now added.
Main stays on the pre-migration build with VAD. The openrpc/herolib migration remains on development for you to land on main intentionally when the consolidation settles (single-struct method inputs, no dot-namespaced names, updated hero_proc_sdk secret API). Leaving this open for that follow-up.
Signed-by: mik-tf mik-tf@noreply.invalid