Fresh hero_osis install has no Context records — root context list is empty after --start #38

New issue

Open

opened 2026-04-27 14:42:01 +00:00 by rawan · 0 comments

rawan commented

2026-04-27 14:42:01 +00:00

Member

Symptom

A freshly installed/started hero_osis (via make start or hero_osis --start) defaults to running with the root context (per ServerCli default), but no Context records exist in storage. As a result, the OSIS admin UI (and the OSIS island in hero_os, once #37 is fixed) shows an empty contexts list with no obvious next step for new users.

Reproduction

cd hero_osis
make start                       # registers + starts hero_osis via hero_proc, default --contexts root

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  -H 'X-Hero-Context: root' \
  -d '{"jsonrpc":"2.0","id":1,"method":"base.context.list","params":{}}' \
  http://127.0.0.1:9988/hero_osis_base/rpc
# → {"jsonrpc":"2.0","result":"","id":1}

The result is the empty string — base.context.list returns no SIDs because no Context objects have been persisted to the root context's storage. The runtime context exists (it's serving requests), but there is no Context record describing itself.

Why this is confusing

"Has root context" is overloaded: there's the runtime tenancy bucket (created by --contexts root) AND the base.Context record describing it. Users only see the second one.
The make mock / make seed targets seed contexts (root, default, geomind, …) but only run as foreground processes (cargo run) and use a separate data dir (./data/mock-db). The hero_proc-managed make start flow has no equivalent and ships zero seed data.
The OSIS island's empty-state copy (crates/hero_osis_app/src/components/contexts.rs:58-63) suggests make mock, but on a hero_proc-managed install that command doesn't persist into the right data dir.

Proposed fix

Pick one or combine:

Option A — auto-bootstrap a self-describing root Context on first start. When the server boots a context whose base.context.list is empty, create a Context { sid: "root", name: "root" } record (and one per --contexts value). Idempotent — only creates if missing. Probably belongs in the base domain init.

Option B — ship a default seed. Add a minimal data/default/{root}/base/context_root.toml (and similar for any default contexts) and have make start / hero_osis --start apply it via --seed-dir if no records exist yet. Document the path so users can extend it.

Option C — improve the empty-state UX. At minimum, change contexts.rs:58-63 so the empty case doesn't suggest make mock (which only works in dev-foreground mode); instead, show a one-click "Create root context" button that issues base.context.set.

Recommend A + C together: A fixes the default install, C handles every other empty-state path.

Acceptance criteria

After make start on a clean install, base.context.list returns at least the root SID.
The OSIS admin UI shows root in the contexts list out of the box.
Behavior is idempotent — restarting the server doesn't duplicate records.
make mock / make seed flows continue to work for fuller seed sets.

## Symptom A freshly installed/started `hero_osis` (via `make start` or `hero_osis --start`) defaults to running with the `root` context (per [`ServerCli` default](https://forge.ourworld.tf/lhumina_code/hero_rpc/src/branch/development/crates/server/src/server/cli.rs#L31-L33)), but no `Context` records exist in storage. As a result, the OSIS admin UI (and the OSIS island in hero_os, once #37 is fixed) shows an empty contexts list with no obvious next step for new users. ## Reproduction ```bash cd hero_osis make start # registers + starts hero_osis via hero_proc, default --contexts root curl -sS -X POST \ -H 'Content-Type: application/json' \ -H 'X-Hero-Context: root' \ -d '{"jsonrpc":"2.0","id":1,"method":"base.context.list","params":{}}' \ http://127.0.0.1:9988/hero_osis_base/rpc # → {"jsonrpc":"2.0","result":"","id":1} ``` The `result` is the empty string — `base.context.list` returns no SIDs because no `Context` objects have been persisted to the root context's storage. The runtime context exists (it's serving requests), but there is no `Context` record describing itself. ## Why this is confusing 1. "Has root context" is overloaded: there's the runtime tenancy bucket (created by `--contexts root`) AND the `base.Context` record describing it. Users only see the second one. 2. The `make mock` / `make seed` targets seed contexts (root, default, geomind, …) but only run as foreground processes (`cargo run`) and use a separate data dir (`./data/mock-db`). The hero_proc-managed `make start` flow has no equivalent and ships zero seed data. 3. The OSIS island's empty-state copy ([crates/hero_osis_app/src/components/contexts.rs:58-63](crates/hero_osis_app/src/components/contexts.rs#L58-L63)) suggests `make mock`, but on a hero_proc-managed install that command doesn't persist into the right data dir. ## Proposed fix Pick one or combine: **Option A — auto-bootstrap a self-describing root Context on first start.** When the server boots a context whose `base.context.list` is empty, create a `Context { sid: "root", name: "root" }` record (and one per `--contexts` value). Idempotent — only creates if missing. Probably belongs in the base domain init. **Option B — ship a default seed.** Add a minimal `data/default/{root}/base/context_root.toml` (and similar for any default contexts) and have `make start` / `hero_osis --start` apply it via `--seed-dir` if no records exist yet. Document the path so users can extend it. **Option C — improve the empty-state UX.** At minimum, change [contexts.rs:58-63](crates/hero_osis_app/src/components/contexts.rs#L58-L63) so the empty case doesn't suggest `make mock` (which only works in dev-foreground mode); instead, show a one-click "Create root context" button that issues `base.context.set`. Recommend A + C together: A fixes the default install, C handles every other empty-state path. ## Acceptance criteria - [ ] After `make start` on a clean install, `base.context.list` returns at least the `root` SID. - [ ] The OSIS admin UI shows `root` in the contexts list out of the box. - [ ] Behavior is idempotent — restarting the server doesn't duplicate records. - [ ] `make mock` / `make seed` flows continue to work for fuller seed sets.