fix: per-rootobject Create input schema; drop bogus *.find from spec #46
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!46
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/input-schema-and-find"
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?
Why
Two OpenRPC-surface cleanups so the spec matches what callers can actually do.
1. Per-rootobject Create input schema
Reusing the full
Taskschema (withsid/created_at/updated_atinjected as required) for*_set.dataforced clients to ship placeholder values (sid="0000",created_at=0, ...) for fields the server overwrites anyway. Generated Python dataclasses inherited the noise.The openrpc generator now also emits
<Name>Createfor every rootobject — same shape minus the server-managed base fields and minus them inrequired[].unified_serverwires*_set.datato<Name>Create; reads keep returning the full<Name>so round-trips stay clean.2. Removed
*.findfrom the auto-CRUD specrust_osis.rs::generate_rpc_methodsonly generates_rpc_new,_rpc_get,_rpc_set,_rpc_delete,_rpc_list,_rpc_exists. There is no_rpc_findhandler. Listing*.findin the spec returned-32601 Method not foundto anyone who tried it (LLM agents in particular). Re-add when DBTyped grows a real query API.Verified
cargo build --releaseclean.cargo test --release --lib --binspasses (the brokenexamples/are stale generated code unrelated to this PR).*Createcompanion schemas.Downstream
hero_osis pulls this via git; rebuilding hero_osis will regenerate its static spec to include
<Name>Createschemas, and the runtime CRUD spec will reference them automatically. Python clients regenerated by hero_router will then emit dataclasses without the placeholder base fields.🤖 Generated with Claude Code
The auto-CRUD `*_rpc_set` handler used to accept either a JSON `data` param or a legacy OTOML `obj` string and fall back transparently between the two. The OTOML fallback no longer pulls its weight: every generated client (Rust/Python/JS) ships JSON, the server returns JSON on every CRUD path (per recent work), and the dual-shape handler muddies error messages — callers who forget the `data` kwarg get "Missing required parameter: data (JSON object) or obj (OTOML string)" pointing at a wire format they shouldn't think about. The generated handler is now JSON-only: Missing required parameter: data (JSON object matching <TypeName>Create schema) The error message names the exact dataclass to construct, so prescriptive error_debug feedback in the agent retry loop can map the failure straight to the right fix. `*_new_from_otoml` still exists on the server-side generated impl for in-process callers (seed scripts, tests). It just isn't reachable through the RPC surface anymore. Co-evolves with hero_rpc PR #46. Recipe_server's regenerated osis_server_generated.rs picks up the slimmer handler shape (~30 lines smaller per rootobject). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>