lhumina_code/hero_demo
0
0
Fork 0
Code Issues 60 Pull requests Projects Releases 2 Packages Wiki Activity Actions

[nu-demo] Switching contexts doesn't work. #44

New issue
Closed
opened 2026-04-28 12:25:43 +00:00 by mik-tf · 2 comments
mik-tf commented 2026-04-28 12:25:43 +00:00
Owner
Copy link

Only the default "Geomind" context works. Trying to switch to another makes this error:

image

Originally filed as home#151 on 2026-04-24 by scott — moved to hero_demo as part of consolidating issue tracking.

Only the default "Geomind" context works. Trying to switch to another makes this error: ![image](/attachments/34f61585-aac7-4c48-bde0-08c8ec081e61) --- *Originally filed as [home#151](https://forge.ourworld.tf/lhumina_code/home/issues/151) on 2026-04-24 by scott — moved to hero_demo as part of consolidating issue tracking.*
mik-tf commented 2026-04-30 02:50:18 +00:00
Author
Owner
Copy link

Update — diagnosed and partially fixed (2026-04-30)

After investigation, "contexts don't work, only Geomind works" turns out to be two distinct problems on top of each other, not a single context-routing bug.

Problem 1 — per-context X-Hero-Context routing (NOT broken, verified)

End-to-end probing on herodemo against the per-domain hero_osis_business socket:

ctx=geomind:   company.list → 6 SIDs (s001, s005, s002, s007, s008, s00a)
ctx=incubaid:  company.list → 8 SIDs
ctx=threefold: company.list → 6 SIDs (different ones, includes s006)
ctx=default:   company.list → 0 (empty — expected, system default)
ctx=root:      company.list → 2 (s005, s002)

Each context returns a distinct dataset. X-Hero-Context routing through hero_proxy → hero_router → per-domain hero_osis socket is healthy. Per-context data isolation works. The bug is not routing.

Problem 2 — dock islands fail to render in non-default contexts (the actual user-visible bug)

What Sameh hit when switching to Incubaid: clicking certain dock items produced
Failed to load island WASM 'room': JsValue(TypeError: Failed to fetch dynamically imported module: .../islands/room/hero_archipelagos_room.js).

Root cause: same class as the OSIS dock 404 already documented in
hero_demo#34 — the island has neither a native dispatcher arm in hero_os_app/src/island_content.rs nor an on-disk WASM bundle at /hero_os/ui/islands/<id>/. The dispatcher's dynamic-loader fallthrough tries import("/hero_os/ui/islands/room/hero_archipelagos_room.js"), nginx serves the catch-all index.html with content-type: text/html, browser rejects the module load.

The user perception "contexts don't work" is because:

  • Geomind dock happens to contain only islands that DO have a working render path on the web build.
  • Incubaid / Threefold / etc. docks contain other islands (room, possibly more) whose feature flags aren't enabled in the web feature list and which lack iframe fallbacks → 404 on click.

What landed for problem 2 this session

  1. hero_os PR #118 → d70af39 — iframe fallback for osis (closes hero_os#112).
  2. hero_os 9303efe — island-videos added to web, Books defaults to iframe /hero_books/ui/ (no more JSON-parse-error from the Dioxus version).
  3. hero_archipelagos 70b9d04 — fix(embed/books): strip trailing slash from base_url (closes home#157).
  4. hero_osis 8a99553 — central /hero_osis/ui/ renders a domain picker instead of hanging on "Loading service spec…" (closes hero_demo#35).

Verified live on herodemo: /hero_osis/ui/ shows the domain picker; per-domain dashboards (/hero_osis_business/ui/ etc.) all return 200; /hero_books/ui/ serves the Knowledge World HTML; new WASM contains the osis-iframe and books-iframe arms; AI Assistant /api/chat returns a streaming response.

What still needs doing for full closure

  • Audit the per-context dock contents. Some contexts (Incubaid in particular) surface island IDs that are not in web's feature list and have no iframe fallback. Each such island needs either:
    • an iframe fallback arm in hero_os_app/src/island_content.rs mirroring the OSIS / Books / Slides / Whiteboard / Collab pattern: #[cfg(not(feature = "island-X-native"))] "X" => rsx! { ExternalServiceIframe { src: "/hero_<X>/ui/", … } }, OR
    • removal from the registry / per-context dock filter if the service doesn't actually exist (architectural dead wood — same call as services in hero_demo#34).
  • The dynamic_loader fallthrough at the bottom of the match is currently the silent failure path — it tries to import /hero_os/ui/islands/<id>/…js which produces "Failed to fetch dynamically imported module" rather than a clear "this island isn't available in this build". Replacing the fallthrough with an explicit error component would surface gaps at click time instead of resembling a network error. Optional.
  • The systematic enumeration of which IDs need iframe arms is mechanical — walk every IslandMetadata::builder("X", …) and <id>_metadata() push in registry.rs, check island_content.rs has either an unconditional arm or an iframe-fallback arm. Items without one are the work list.

Conclusion

The routing layer (X-Hero-Context → per-domain socket → context-scoped DB) is healthy. The user-visible "contexts don't work" symptom is the dock-island gap from hero_demo#34, just spread across non-default contexts. Track A from this session (Books / Videos / OSIS iframe + central picker) closes the most-visible cases; the remaining work is enumeration + iframe-fallback arms for any island still hitting the dynamic-loader fallthrough.

Suggest re-titling this issue to "Some islands fail to render in non-default contexts (dock-island gap, sibling of #34)" — the original title is misleading because context switching itself works.

Signed-off-by: mik-tf

## Update — diagnosed and partially fixed (2026-04-30) After investigation, "contexts don't work, only Geomind works" turns out to be **two distinct problems** on top of each other, not a single context-routing bug. ### Problem 1 — per-context X-Hero-Context routing (NOT broken, verified) End-to-end probing on herodemo against the per-domain hero_osis_business socket: ``` ctx=geomind: company.list → 6 SIDs (s001, s005, s002, s007, s008, s00a) ctx=incubaid: company.list → 8 SIDs ctx=threefold: company.list → 6 SIDs (different ones, includes s006) ctx=default: company.list → 0 (empty — expected, system default) ctx=root: company.list → 2 (s005, s002) ``` Each context returns a distinct dataset. X-Hero-Context routing through hero_proxy → hero_router → per-domain hero_osis socket is healthy. **Per-context data isolation works.** The bug is not routing. ### Problem 2 — dock islands fail to render in non-default contexts (the actual user-visible bug) What Sameh hit when switching to Incubaid: clicking certain dock items produced `Failed to load island WASM 'room': JsValue(TypeError: Failed to fetch dynamically imported module: .../islands/room/hero_archipelagos_room.js)`. Root cause: same class as the OSIS dock 404 already documented in [hero_demo#34](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/34) — the island has neither a native dispatcher arm in `hero_os_app/src/island_content.rs` nor an on-disk WASM bundle at `/hero_os/ui/islands/<id>/`. The dispatcher's dynamic-loader fallthrough tries `import("/hero_os/ui/islands/room/hero_archipelagos_room.js")`, nginx serves the catch-all index.html with `content-type: text/html`, browser rejects the module load. The user perception "contexts don't work" is because: - **Geomind** dock happens to contain only islands that DO have a working render path on the `web` build. - **Incubaid / Threefold / etc.** docks contain other islands (`room`, possibly more) whose feature flags aren't enabled in the `web` feature list and which lack iframe fallbacks → 404 on click. ### What landed for problem 2 this session 1. [hero_os PR #118](https://forge.ourworld.tf/lhumina_code/hero_os/pulls/118) → `d70af39` — iframe fallback for `osis` (closes [hero_os#112](https://forge.ourworld.tf/lhumina_code/hero_os/issues/112)). 2. [hero_os `9303efe`](https://forge.ourworld.tf/lhumina_code/hero_os/commit/9303efe) — `island-videos` added to `web`, Books defaults to iframe `/hero_books/ui/` (no more JSON-parse-error from the Dioxus version). 3. [hero_archipelagos `70b9d04`](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/commit/70b9d04) — `fix(embed/books): strip trailing slash from base_url` (closes [home#157](https://forge.ourworld.tf/lhumina_code/home/issues/157)). 4. [hero_osis `8a99553`](https://forge.ourworld.tf/lhumina_code/hero_osis/commit/8a99553) — central `/hero_osis/ui/` renders a domain picker instead of hanging on "Loading service spec…" (closes [hero_demo#35](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/35)). Verified live on herodemo: `/hero_osis/ui/` shows the domain picker; per-domain dashboards (`/hero_osis_business/ui/` etc.) all return 200; `/hero_books/ui/` serves the Knowledge World HTML; new WASM contains the `osis-iframe` and `books-iframe` arms; AI Assistant `/api/chat` returns a streaming response. ### What still needs doing for full closure - **Audit the per-context dock contents.** Some contexts (Incubaid in particular) surface island IDs that are not in `web`'s feature list and have no iframe fallback. Each such island needs either: - an iframe fallback arm in `hero_os_app/src/island_content.rs` mirroring the OSIS / Books / Slides / Whiteboard / Collab pattern: `#[cfg(not(feature = "island-X-native"))] "X" => rsx! { ExternalServiceIframe { src: "/hero_<X>/ui/", … } }`, OR - removal from the registry / per-context dock filter if the service doesn't actually exist (architectural dead wood — same call as `services` in hero_demo#34). - The `dynamic_loader` fallthrough at the bottom of the `match` is currently the silent failure path — it tries to import `/hero_os/ui/islands/<id>/…js` which produces "Failed to fetch dynamically imported module" rather than a clear "this island isn't available in this build". Replacing the fallthrough with an explicit error component would surface gaps at click time instead of resembling a network error. Optional. - The systematic enumeration of which IDs need iframe arms is mechanical — walk every `IslandMetadata::builder("X", …)` and `<id>_metadata()` push in `registry.rs`, check `island_content.rs` has either an unconditional arm or an iframe-fallback arm. Items without one are the work list. ### Conclusion The **routing layer (X-Hero-Context → per-domain socket → context-scoped DB) is healthy**. The user-visible "contexts don't work" symptom is the dock-island gap from `hero_demo#34`, just spread across non-default contexts. Track A from this session (Books / Videos / OSIS iframe + central picker) closes the most-visible cases; the remaining work is enumeration + iframe-fallback arms for any island still hitting the dynamic-loader fallthrough. Suggest re-titling this issue to *"Some islands fail to render in non-default contexts (dock-island gap, sibling of #34)"* — the original title is misleading because context switching itself works. Signed-off-by: mik-tf
mik-tf commented 2026-04-30 11:11:57 +00:00
Author
Owner
Copy link

Fixed

Fixed
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
v0.9.3-dev
v0.9.0-dev
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_demo#44
No description provided.