hero_rpc2: OpenRpcDocument::from_value constructor (#90 framework gap) #99
No reviewers
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_rpc!99
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-90-openrpc-from-value"
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?
Small framework addition surfaced while migrating hero_service onto hero_rpc2 in #90 Phase 2.
OSIS services build their OpenRPC document offline via codegen (the canonical
<workspace>/docs/openrpc.jsonlayout from #73) andinclude_str!it into the binary. Wiring it throughServerBuilder::with_discoverwas impossible — the existing API only accepted documents that the in-processOpenRpcBuilderhad constructed from typedJsonSchemaregistrations, with no constructor to lift a rawserde_json::Valueinto the wrappingOpenRpcDocumentnewtype.One-line addition:
OpenRpcDocument::from_value(Value) -> Self. Same no-validation contractOpenRpcBuilder::build()has (the doc the builder produces also isn't validated against the spec — the convention is "the producer is responsible for correctness").Test:
tests/http_well_known.rs::openrpc_json_endpoint_returns_doc_from_valuepins the round-trip — value in viafrom_value, exact same JSON out viaGET /openrpc.json.Unblocks the Phase 2 / 3 / 4 service migrations on #90; every OSIS service now wires
with_discover(OpenRpcDocument::from_value(parsed_spec))with their embeddeddocs/openrpc.json.