[nu-demo] hero_biz never refactored for OSIS per-domain split — Hero0Config legacy facade returns empty data even with correct URL #180
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?
Symptom
The standalone HeroBiz iframe (
/hero_biz/ui/c/<context>) renders the dashboard chrome correctly (sidebar, top bar, layout) but every counter shows 0 and every list (Persons, Companies, Contacts, Opportunities, Deals, Instruments, Contracts, Transactions) is empty — across all contexts (threefold, geomind, incubaid).Meanwhile the native Business archipelago island (Dioxus WASM,
hero_archipelagos/archipelagos/business) shows real data on the same VM: 6 Persons / 6 Companies / 4 Contacts / 4 Opportunities / 6 Deals / 5 Instruments / 7 Contracts / 15 Transactions for the same contexts — fetched from the same per-domain OSIS servers via the samehero_osis_sdkclients.Root cause — architectural gap from the OSIS per-domain split
The split moved OSIS from a single monolithic
hero_osis_server(one/hero_osis/rpcendpoint serving all domains) to 17 per-domain servers (hero_osis_business,hero_osis_identity, …) each on its own Unix socket. Thehero_osis_sdkclients were redesigned for this:hero_rpc/crates/openrpc_http_client_lib/src/lib.rs:151-155—OsisClient::new(base_url, context, domain)constructs{base_url}/hero_osis_{domain}/rpcand sendsX-Hero-Context: {context}on every call.hero_router/src/server/routes.rs:1941-1948— generic/:service_name/:webnameproxy maps that path to the per-domain Unix socket. No/hero_osis/...aggregator route exists (and the architecture deliberately does not have one).IslandContext::osis_url()(router origin or relative"") and threads it to per-domain SDK clients. Works on herodemo right now.HeroBiz iframe (
hero_biz_uiAxum server) was never refactored for this split. Three concrete bugs:hero_biz_app/src/rpc.rs:42(the WASM island variant): hardcodes a POST to/hero_osis/rpc/rpc— the legacy monolithic endpoint that no longer exists.hero_biz_ui/src/hero0/mod.rs:71-99—Hero0Configholds 8 per-domain clients sharing onebase_url. This was correct for the monolithic era. With per-domain split, even the rightbase_urlcan't make all 8 clients route correctly through one URL because each client needs_<domain>in its path (the SDK appends this if you pass the router-root base — but Hero0Config never passesIslandContext.osis_url()through; it readsHERO0_BASE_URLfrom env).hero_skills/tools/modules/services/service_biz.nu:131-132+hero_demo/services/hero_biz.toml:14— both hardcodeHERO0_BASE_URL=http://127.0.0.1:6666/hero_osis/uiwhich is doubly wrong post-split: port 6666 is not where hero_router binds (router runs on10.1.2.2:9988), and/hero_osis/uiis not a valid prefix in the per-domain world.Demo experiment 2026-04-24
I tried fixing this with config alone:
HERO0_BASE_URL=http://10.1.2.2:9988on hero_biz_ui's action env (the actual hero_router root).cat /proc/$pid/environshows the new value.curl POST http://10.1.2.2:9988/hero_osis_business/rpc -H 'X-Hero-Context: threefold'returns 6 person SIDs.hero_biz_ui/src/services/mod.rs:208actually callsBusinessClient::person_list()(not some other code path).Result: dashboard still shows empty. Even with the right URL and the SDK doing its job upstream of the wrapper,
Store::load_all_persons_for_space("threefold")returnsOk(vec![]). There is a deeper bug inhero_biz_ui::Hero0(or its caching layer atservices/mod.rs:33-90) beyond just the env-var. Tracing further would require enabling debug logs and instrumenting the request path — out of scope for a hotfix.Conclusion
This is not a setup bug — it's a real codebase regression that the OSIS per-domain split introduced and never fixed in
hero_biz_ui/hero_biz_app. The hero_biz package was effectively orphaned during the split, even though its installer (service_biz.nu) and service config (hero_demo/services/hero_biz.toml) still ship it.Devops vision for the fix
Per the SDK's own design and the working native Business island, the canonical pattern is per-domain URL construction by the SDK, with a single router-root
base_urlshared across all per-domain clients. The fix inhero_biz:Drop
Hero0Configlegacy facade — replace with direct per-domain SDK clients (BusinessClient,ProjectsClient,IdentityClient,CalendarClient,FilesClient,CommunicationClient,FinanceClient,AiClient).Server-side (
hero_biz_ui/src/services/mod.rs):Storeconstructs each per-domain client withbase_url=HERO0_BASE_URL(router root, e.g.http://10.1.2.2:9988or unix-socket-via-some-shim) andcontext= the route's context. SDK handles the rest.WASM-side (
hero_biz_app/src/app.rs): acceptIslandContext(already does at line 72) and passIslandContext.osis_url()to per-domain SDK clients. Drophero_biz_app/src/rpc.rs:42's hardcoded/hero_osis/rpc/rpcPOST entirely.Installer:
service_biz.nu:131-132+hero_demo/services/hero_biz.toml:14should setHERO0_BASE_URLto the hero_router root URL, not a service-prefixed path.Tests: smoke test that hits
/hero_biz/ui/c/threefold/personsand asserts at least one row when OSIS has data.Related
hero_osis_uiadmin UI (no aggregator, per-domain discovery never completes)/hero_biz/(fixed); but even with the right URL, the data layer is still broken (this issue)Demo workaround on herodemo (2026-04-24)
HERO0_BASE_URLpatched tohttp://10.1.2.2:9988viahero_proc action.set(better than the broken default but doesn't unblock data display until the code refactor lands). Native Business island remains the working answer for now.Signed-off-by: mik-tf
mik-tf referenced this issue2026-04-25 23:00:36 +00:00
Resolved
Landed across three repos on
development(squash commits):hero_bizc3d338f — per-domain SDK migration: dropHero0Configfacade, rewriteStorewithBusinessClient/ProjectsClientlazy-cached per context, drop the WASMosis_rpcraw POST, rewrite all 9 tabs onto a typedBizServiceslayer, addhero_biz_appto workspace.hero_skills7d47605 —service_biz.nuderivesHERO0_BASE_URLfromHERO_ROUTER_ADDRESS/HERO_ROUTER_UI_PORT(router root only; no/hero_osis/uisuffix).hero_demo8f4159b — drop the staleHERO0_BASE_URL = http://127.0.0.1:6666/hero_osis/uipin fromservices/hero_biz.toml; runbook §4.4 / §8 / §13 updated.Root cause
The architecture work (per-domain SDK, drop Hero0Config, fix WASM rpc, drop URL suffix) was all needed, but the specific blocker for live data was a
Cargo.lockgit-pin:hero_rpc_clientwas pinned to commitbbd118ca, which still built endpoints with the legacy/rpc/{context}URL format. hero_router post-split has no route for that shape and 404s; the hero_biz_ui handler thenunwrap_or_default()'d the error and rendered an empty table — exactly the symptom this issue described as the "deeper bug."cargo update -p hero_rpc_clientadvanced the pin to38a09290, which containsed6e7eb's switch to/hero_osis_{domain}/rpc+X-Hero-Contextheader. This is exactly the trap thefeedback_cargo_lock_git_depsskill warns about.Verification on herodemo (2026-04-26)
/hero_biz/ui/c/threefold/persons(via hero_router)/hero_biz/ui/c/threefold/{companies,contacts,opportunities,deals,instruments,contracts}/hero_biz/ui/c/geomind/personsand/incubaid/personshttps://herodemo.gent01.grid.tf/hero_osis_business/rpc(auth-bypassed RPC path)tracinglogsperson_list(threefold) -> 6 SIDs,load_all_persons -> 6 personsUser confirmed in browser that the Biz iframe is seeded and renders.
Workflow note for future deployers
The runbook §3 already says to export
HERO_ROUTER_ADDRESS=10.1.2.2andHERO_ROUTER_UI_PORT=9990in~/hero/cfg/env/env.shon TF Grid VMs. herodemo's env.sh was missing both — added during this deploy. Without them,service_biz.nu's default falls back to127.0.0.1:9988which is unbound on TF Grid VMs (router is on10.1.2.2:9990, nginx on10.1.2.2:9988). Worth a one-line check ininstall_corelater.Signed-off-by: mik-tf