Regenerate clients with delete returning serde_json::Value #36

Merged

fatmaebrahim merged 2 commits from development_fix_delete_deserialization_error into development

2026-04-28 06:45:15 +00:00

fatmaebrahim commented

2026-04-27 10:43:24 +00:00

Member

Summary

Regenerated all 15 osis_client_generated.rs files so every CRUD _delete method uses rpc_call::<serde_json::Value> instead of rpc_call::<String>.

Why

Server *_rpc_delete handlers return deleted.to_string() ("true"/"false"). The dispatch layer in hero_rpc auto-parses that string as JSON before placing it in the response — so the wire result is a JSON bool, not a JSON string. The old SDK used rpc_call::<String> and rejected the bool with invalid type: boolean true, expected a string at line 1 column 30. The delete already happened server-side; only the UI saw an error.

Using Value makes the SDK tolerant of whatever shape the dispatch produces, which is the correct posture for a discarded return value.

Scope

15 files, one _delete per CRUD type, mechanical regeneration.
Public API unchanged: signature is still pub async fn xxx_delete(&self, sid: &str) -> Result<(), ClientError>.
Compiles clean on native + wasm32-unknown-unknown.
Verified end-to-end: rebuilt hero_os WASM with this SDK and confirmed contact/contract/deal delete works without the deserialization error.

Refs

Pairs with: lhumina_code/hero_rpc#33 (the generator-side fix)
Refs: lhumina_code/hero_os#49

## Summary Regenerated all 15 `osis_client_generated.rs` files so every CRUD `_delete` method uses `rpc_call::<serde_json::Value>` instead of `rpc_call::<String>`. ## Why Server `*_rpc_delete` handlers return `deleted.to_string()` (`"true"`/`"false"`). The dispatch layer in hero_rpc auto-parses that string as JSON before placing it in the response — so the wire result is a JSON bool, not a JSON string. The old SDK used `rpc_call::<String>` and rejected the bool with `invalid type: boolean true, expected a string at line 1 column 30`. The delete already happened server-side; only the UI saw an error. Using `Value` makes the SDK tolerant of whatever shape the dispatch produces, which is the correct posture for a discarded return value. ## Scope - 15 files, one `_delete` per CRUD type, mechanical regeneration. - Public API unchanged: signature is still `pub async fn xxx_delete(&self, sid: &str) -> Result<(), ClientError>`. - Compiles clean on native + `wasm32-unknown-unknown`. - Verified end-to-end: rebuilt hero_os WASM with this SDK and confirmed contact/contract/deal delete works without the deserialization error. ## Refs - Pairs with: lhumina_code/hero_rpc#33 (the generator-side fix) - Refs: lhumina_code/hero_os#49

fatmaebrahim added 1 commit

2026-04-27 10:43:24 +00:00

fix(sdk): regenerate clients with delete returning serde_json::Value

Build and Test / build (pull_request) Successful in 4m38s

Details

82ce503305

Regenerated all 15 osis_client_generated.rs files to apply the generator
fix from lhumina_code/hero_rpc: every CRUD `_delete` method now uses
rpc_call::<serde_json::Value> instead of rpc_call::<String>.

Unblocks the contact / contract / deal delete UI in hero_archipelagos,
which threw "invalid type: boolean true, expected a string at line 1
column 30" on every successful delete because the server's stringified
bool is auto-parsed back to a JSON bool by the dispatch layer.

Pairs with: lhumina_code/hero_rpc PR #33
Refs: lhumina_code/hero_os#49

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

fatmaebrahim changed title from ~~fix(sdk): regenerate clients with delete returning serde_json::Value~~ to Regenerate clients with delete returning serde_json::Value

2026-04-27 11:48:33 +00:00

fatmaebrahim added 1 commit

2026-04-28 06:17:08 +00:00

fix: run cargo --fmt

Build and Test / build (pull_request) Successful in 4m47s

Details

846faa4864

fatmaebrahim force-pushed development_fix_delete_deserialization_error from 846faa4864

Build and Test / build (pull_request) Successful in 4m47s

Details

to 188b0e7c57

Build Linux / build-linux (linux-amd64-musl, false, x86_64-unknown-linux-musl) (pull_request) Successful in 4m35s