OSIS island still 404s on default web build — no bundle path available even after PR #103 #112

Closed
opened 2026-04-29 15:31:16 +00:00 by sameh-farouk · 0 comments
Member

Context

#44 reported Failed to load island WASM 'osis': Island not found: osis (HTTP 404) and was closed today by PR #103 (loader URL fix: /islands/.../hero_os/ui/islands/...).

PR #103 is correct and necessary — but it only unblocks islands that already have a bundle on disk. PR #103's own test note acknowledges this:

playwright trace: services WASM now loads (200 OK); secondary backend 404s are separate deployment issues.

The OSIS 404 is one of those "separate deployment issues" — and it's a deterministic, reproducible code/config gap, not a deployment artifact. Filing this as a narrower follow-up so OSIS doesn't get conflated with #44.

Reproduction

  1. Build hero_os with WASM_FEATURES=web (the default).
  2. Open the OS UI, click the OSIS dock icon.
  3. Network tab shows GET /hero_os/ui/islands/osis/hero_archipelagos_osis.js → 404. The URL is now correct (post-PR-#103); the file doesn't exist.

Two render paths exist; default web build has zero of them for OSIS

The shell can render an island via either:

  • Native path — feature-gated _app crate compiled into hero_os_app's main WASM. Controlled by an island-<name>-native cargo feature.
  • Lazy path — separate hero_archipelagos_<name> crate that make install builds with wasm-pack and drops at /islands/<name>/hero_archipelagos_<name>.js.

For OSIS, neither is available on the default build:

Native path is gated out of web

In crates/hero_os_app/Cargo.toml on development:

  • L91: island-osis-native = ["dep:hero_osis_app", "native-bootstrap"] — feature exists.
  • L116-134 (web = …): does not list island-osis-native.
  • L138-155 (web-native = …): does include island-osis-native at L149.

So WASM_FEATURES=web (the default) compiles hero_os_app without hero_osis_app, and the dispatcher's #[cfg(feature = "island-osis-native")] arm is absent at runtime.

Lazy path doesn't exist at all

hero_archipelagos's tree on development (879 entries) has no OSIS island crate. The 17 archipelagos under archipelagos/:

archipelagos, browser, business, calendar, code, communication,
contacts, editor, embed, files, intelligence, library, messaging,
mycelium, productivity, system, viewer

The only OSIS-named blob is archipelagos/intelligence/intelligence/src/views/knowledge/osis_picker.rs — that's an OSIS-aware view inside the intelligence island, not a standalone OSIS island. There is no hero_archipelagos_osis package, so make install produces nothing at /islands/osis/....

Workaround (Mik documented this in home#171)

Build hero_os with WASM_FEATURES=web-native instead of the default web. That pulls in island-osis-native, which links hero_osis_app into the main WASM and makes the dispatcher render OSIS via the native path. The lazy path stays unavailable, but it's not needed if native is compiled in.

This is a deliberate parallel track per Mik's reply on home#190: the _app crates / island-*-native features are a 100% SPA migration that's intentionally not the default while Kristof's direction is "not yet."

Fix options

One of these needs to land for OSIS to work on the default web build (in priority order, cheapest first):

  1. Add island-osis-native to the default web feature in hero_os_app/Cargo.toml. One-line change. Bypasses the parallel-track policy specifically for OSIS, which has no iframe alternative — unlike islands like collab and whiteboard that have iframe fallbacks documented in home#171.
  2. Create a hero_archipelagos_osis crate so make install produces an /islands/osis/... bundle. More work but keeps the OSIS island on the lazy path and aligns with the convention used for system islands like services.

The right choice depends on the answer to the open architectural question in home#190 — "Convention question: parallel _app Dioxus crates and island-*-native features — finish, repurpose, or deprecate?"

Why this matters

Until one of the fixes above lands, every default-build deployment ships a dock that includes an OSIS tile that 404s on click. Operators can rebuild with WASM_FEATURES=web-native as a workaround, but that's not the documented default install path.

## Context [#44](https://forge.ourworld.tf/lhumina_code/hero_os/issues/44) reported `Failed to load island WASM 'osis': Island not found: osis (HTTP 404)` and was closed today by [PR #103](https://forge.ourworld.tf/lhumina_code/hero_os/pulls/103) (loader URL fix: `/islands/...` → `/hero_os/ui/islands/...`). PR #103 is correct and necessary — but it only unblocks islands that **already have a bundle on disk**. PR #103's own test note acknowledges this: > playwright trace: services WASM now loads (200 OK); **secondary backend 404s are separate deployment issues**. The OSIS 404 is one of those "separate deployment issues" — and it's a deterministic, reproducible code/config gap, not a deployment artifact. Filing this as a narrower follow-up so OSIS doesn't get conflated with #44. ## Reproduction 1. Build hero_os with `WASM_FEATURES=web` (the default). 2. Open the OS UI, click the OSIS dock icon. 3. Network tab shows `GET /hero_os/ui/islands/osis/hero_archipelagos_osis.js → 404`. The URL is now correct (post-PR-#103); the file doesn't exist. ## Two render paths exist; default `web` build has zero of them for OSIS The shell can render an island via either: - **Native path** — feature-gated `_app` crate compiled into `hero_os_app`'s main WASM. Controlled by an `island-<name>-native` cargo feature. - **Lazy path** — separate `hero_archipelagos_<name>` crate that `make install` builds with `wasm-pack` and drops at `/islands/<name>/hero_archipelagos_<name>.js`. For OSIS, neither is available on the default build: ### Native path is gated out of `web` In `crates/hero_os_app/Cargo.toml` on `development`: - L91: `island-osis-native = ["dep:hero_osis_app", "native-bootstrap"]` — feature exists. - L116-134 (`web` = …): does **not** list `island-osis-native`. - L138-155 (`web-native` = …): does include `island-osis-native` at L149. So `WASM_FEATURES=web` (the default) compiles `hero_os_app` without `hero_osis_app`, and the dispatcher's `#[cfg(feature = "island-osis-native")]` arm is absent at runtime. ### Lazy path doesn't exist at all `hero_archipelagos`'s tree on `development` (879 entries) has no OSIS island crate. The 17 archipelagos under `archipelagos/`: ``` archipelagos, browser, business, calendar, code, communication, contacts, editor, embed, files, intelligence, library, messaging, mycelium, productivity, system, viewer ``` The only OSIS-named blob is `archipelagos/intelligence/intelligence/src/views/knowledge/osis_picker.rs` — that's an OSIS-aware view inside the intelligence island, not a standalone OSIS island. There is no `hero_archipelagos_osis` package, so `make install` produces nothing at `/islands/osis/...`. ## Workaround (Mik documented this in [home#171](https://forge.ourworld.tf/lhumina_code/home/issues/171)) Build hero_os with `WASM_FEATURES=web-native` instead of the default `web`. That pulls in `island-osis-native`, which links `hero_osis_app` into the main WASM and makes the dispatcher render OSIS via the native path. The lazy path stays unavailable, but it's not needed if native is compiled in. This is a deliberate parallel track per Mik's reply on [home#190](https://forge.ourworld.tf/lhumina_code/home/issues/190): the `_app` crates / `island-*-native` features are a 100% SPA migration that's intentionally not the default while Kristof's direction is "not yet." ## Fix options One of these needs to land for OSIS to work on the default `web` build (in priority order, cheapest first): 1. **Add `island-osis-native` to the default `web` feature** in `hero_os_app/Cargo.toml`. One-line change. Bypasses the parallel-track policy specifically for OSIS, which has no iframe alternative — unlike islands like `collab` and `whiteboard` that have iframe fallbacks documented in home#171. 2. **Create a `hero_archipelagos_osis` crate** so `make install` produces an `/islands/osis/...` bundle. More work but keeps the OSIS island on the lazy path and aligns with the convention used for system islands like `services`. The right choice depends on the answer to the open architectural question in [home#190](https://forge.ourworld.tf/lhumina_code/home/issues/190) — "Convention question: parallel _app Dioxus crates and island-*-native features — finish, repurpose, or deprecate?" ## Why this matters Until one of the fixes above lands, every default-build deployment ships a dock that includes an OSIS tile that 404s on click. Operators can rebuild with `WASM_FEATURES=web-native` as a workaround, but that's not the documented default install path.
Sign in to join this conversation.
No milestone
No project
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_os#112
No description provided.