[nu-demo] CRUD delete across hero_osis SDK — server returns bool, SDK expects String (confirmed on contact.delete) #20

New issue

Open

opened 2026-04-28 12:20:26 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-04-28 12:20:26 +00:00

Owner

Symptom

In the Contacts island on heronu.gent01.grid.tf, clicking the red delete button on a contact yields:

Deserialization error: invalid type: boolean `true`, expected a string at line 1 column 30

The contact IS deleted server-side (create+delete both work on the backend), but the UI surfaces a hard error banner because the SDK client can't deserialize the {"result": true} response.

Create works cleanly. Delete fails on every CRUD domain I've spot-checked.

Root cause

Tracked already at hero_osis#29 — project.delete (and siblings) returns bool, SDK expects String. contact.delete is the same pattern on the identity / contacts domain.

Every per-domain *.delete method (base/identity/calendar/business/projects/media/files/communication/network/...) is likely affected unless individually remediated.

Demo workaround

None practical — requires SDK regen + rebuild of hero_os_app WASM. For the demo we leave the red banner.

Proper fix

Pick one:

Server-side — change all *.delete methods to return {deleted: true} or {sid: "sXXX"} or bare "" (string) instead of a bare boolean. Regenerate SDKs.
SDK-side — treat all *.delete results as serde_json::Value and accept true / "" / any successful JSON value as success; only the RPC-level error field indicates failure.

Option 2 is more robust — future OpenRPC spec drift won't break anything. Option 1 is simpler but has to be done N times (once per domain, ~17 domains).

Regardless: a single-PR sweep across every domain's delete handler + a test that asserts round-trip via the SDK.

hero_osis#29 — parent issue
home#124 — UX epic: these hard-error banners should be polished empty-states with inline retry, not red stack traces

Filed 2026-04-23 nu-shell demo. Signed-off-by: mik-tf

Originally filed as home#143 on 2026-04-23 by mik-tf — moved to hero_demo as part of consolidating issue tracking.

## Symptom In the Contacts island on heronu.gent01.grid.tf, clicking the red delete button on a contact yields: ``` Deserialization error: invalid type: boolean `true`, expected a string at line 1 column 30 ``` The contact IS deleted server-side (create+delete both work on the backend), but the UI surfaces a hard error banner because the SDK client can't deserialize the `{"result": true}` response. Create works cleanly. Delete fails on every CRUD domain I've spot-checked. ## Root cause Tracked already at [hero_osis#29](https://forge.ourworld.tf/lhumina_code/hero_osis/issues/29) — `project.delete` (and siblings) returns bool, SDK expects String. `contact.delete` is the same pattern on the `identity` / `contacts` domain. Every per-domain `*.delete` method (base/identity/calendar/business/projects/media/files/communication/network/...) is likely affected unless individually remediated. ## Demo workaround None practical — requires SDK regen + rebuild of hero_os_app WASM. For the demo we leave the red banner. ## Proper fix Pick one: 1. **Server-side** — change all `*.delete` methods to return `{deleted: true}` or `{sid: "sXXX"}` or bare `""` (string) instead of a bare boolean. Regenerate SDKs. 2. **SDK-side** — treat all `*.delete` results as `serde_json::Value` and accept `true` / `""` / any successful JSON value as success; only the RPC-level `error` field indicates failure. Option 2 is more robust — future OpenRPC spec drift won't break anything. Option 1 is simpler but has to be done N times (once per domain, ~17 domains). Regardless: a single-PR sweep across every domain's delete handler + a test that asserts round-trip via the SDK. ## Related - hero_osis#29 — parent issue - home#124 — UX epic: these hard-error banners should be polished empty-states with inline retry, not red stack traces Filed 2026-04-23 nu-shell demo. Signed-off-by: mik-tf --- *Originally filed as [home#143](https://forge.ourworld.tf/lhumina_code/home/issues/143) on 2026-04-23 by mik-tf — moved to hero_demo as part of consolidating issue tracking.*