Browser app: API Docs tab fails ("Unexpected end of JSON input") + health-check report #11

New issue

Closed

opened 2026-04-26 12:26:37 +00:00 by salmaelsoly · 2 comments

salmaelsoly commented 2026-04-26 12:26:37 +00:00

Member

Copy link

Found while testing the Browser app (iframed in hero_os from /hero_browser/ui/).

1. API Docs tab fails to load

Steps

1. Open the Browser app in hero_os
2. Click the API Docs tab

Expected: tab shows the OpenRPC method documentation (grouped accordion).

Actual: shows

Failed to load API docs: Failed to execute 'json' on 'Response': Unexpected end of JSON input

Root cause
crates/hero_browser_ui/templates/index.html:180 does:

const resp = await fetch("{{ base_path }}/openrpc.json");

With base_path = /hero_browser/ui (set from X-Forwarded-Prefix by hero_router), this fetches /hero_browser/ui/openrpc.json. hero_router routes /<svc>/ui/... to ui.sock, but hero_browser_ui has no /openrpc.json route — the spec is served by hero_browser_server on rpc.sock. The UI returns 404 with an empty body, which await resp.json() then chokes on.

Verified via curl:

• GET /hero_browser/ui/openrpc.json → 404, empty body
• GET /hero_browser/ui/rpc/openrpc.json → 200 OK, full spec (sibling shortcut: hero_router rewrites /<svc>/ui/rpc[/…] → rpc.sock, see hero_router/src/server/routes.rs:1062-1106)
• GET /hero_browser/rpc/openrpc.json → 200 OK (direct rpc prefix, also fine)

Suggested fix (one line)

- const resp = await fetch("{{ base_path }}/openrpc.json");
+ const resp = await fetch("{{ base_path }}/rpc/openrpc.json");

Same bug, second instance
crates/hero_browser_ui/templates/base.html:26 — the navbar OpenRPC button:

<a href="{{ base_path }}/openrpc.json" target="_blank" …>

Opens a 404 page in a new tab for the same reason. Should become {{ base_path }}/rpc/openrpc.json.

2. Health check fails

Reported alongside the above
Need to reproduce: where is the failure visible — the connection-status dot in the navbar, a console error, a popover row showing ❌, or somewhere else? A DevTools Network/Console screenshot would pinpoint it. Possibly related to Item 1 (the only failing endpoint observed in this dashboard so far).

Found while testing the Browser app (iframed in hero_os from `/hero_browser/ui/`). ## 1. API Docs tab fails to load **Steps** 1. Open the Browser app in hero_os 2. Click the **API Docs** tab **Expected**: tab shows the OpenRPC method documentation (grouped accordion). **Actual**: shows ``` Failed to load API docs: Failed to execute 'json' on 'Response': Unexpected end of JSON input ``` **Root cause** `crates/hero_browser_ui/templates/index.html:180` does: ```js const resp = await fetch("{{ base_path }}/openrpc.json"); ``` With `base_path = /hero_browser/ui` (set from `X-Forwarded-Prefix` by hero_router), this fetches `/hero_browser/ui/openrpc.json`. hero_router routes `/<svc>/ui/...` to `ui.sock`, but `hero_browser_ui` has no `/openrpc.json` route — the spec is served by `hero_browser_server` on `rpc.sock`. The UI returns `404` with an empty body, which `await resp.json()` then chokes on. Verified via curl: - `GET /hero_browser/ui/openrpc.json` → `404`, empty body - `GET /hero_browser/ui/rpc/openrpc.json` → `200 OK`, full spec (sibling shortcut: hero_router rewrites `/<svc>/ui/rpc[/…]` → `rpc.sock`, see `hero_router/src/server/routes.rs:1062-1106`) - `GET /hero_browser/rpc/openrpc.json` → `200 OK` (direct rpc prefix, also fine) **Suggested fix (one line)** ```diff - const resp = await fetch("{{ base_path }}/openrpc.json"); + const resp = await fetch("{{ base_path }}/rpc/openrpc.json"); ``` **Same bug, second instance** `crates/hero_browser_ui/templates/base.html:26` — the navbar **OpenRPC** button: ```html <a href="{{ base_path }}/openrpc.json" target="_blank" …> ``` Opens a 404 page in a new tab for the same reason. Should become `{{ base_path }}/rpc/openrpc.json`. ## 2. Health check fails Reported alongside the above **Need to reproduce**: where is the failure visible — the connection-status dot in the navbar, a console error, a popover row showing `❌`, or somewhere else? A DevTools Network/Console screenshot would pinpoint it. Possibly related to Item 1 (the only failing endpoint observed in this dashboard so far).

salmaelsoly commented 2026-04-26 12:36:50 +00:00

Author

Member

Copy link

Implementation Spec for Issue #11

Objective

Fix the broken /openrpc.json URL in two places in hero_browser_ui so it routes through hero_router's ui/rpc[/...] sibling shortcut, which forwards to rpc.sock where the spec is actually served.

Requirements

• Item 1 (API Docs tab): tab loads the OpenRPC method documentation instead of the JSON-parse error.
• Item 2 (navbar OpenRPC button): button opens the spec instead of a 404 page.
• No new dependencies, no router or backend changes — UI-only template edits.
• Health-check item from the original report kept open pending repro details (UI/rpc.health/browser_list endpoints all return 200 from curl).

Files to Modify

• crates/hero_browser_ui/templates/index.html — change the fetch() URL in the API Docs tab loader.
• crates/hero_browser_ui/templates/base.html — change the OpenRPC <a href=""> in the navbar.

Implementation Plan

Step 1: Patch both template URLs

Files: crates/hero_browser_ui/templates/index.html, crates/hero_browser_ui/templates/base.html

• index.html:180: fetch("{{ base_path }}/openrpc.json") -> fetch("{{ base_path }}/rpc/openrpc.json")
• base.html:26: href="{{ base_path }}/openrpc.json" -> href="{{ base_path }}/rpc/openrpc.json"
  Dependencies: none

Step 2: Build and runtime-verify

• cargo build -p hero_browser_ui (release)
• Restart the hero_browser_ui action via hero_proc so the new templates take effect
• curl both URLs through hero_router to confirm 200 + JSON body:
  • GET /hero_browser/ui/rpc/openrpc.json
  • GET /hero_browser/rpc/openrpc.json (control)
    Dependencies: Step 1

Acceptance Criteria

• API Docs tab in the Browser app renders the accordion of method groups (no JSON parse error).
• Navbar OpenRPC button opens the spec in a new tab.
• cargo build -p hero_browser_ui succeeds.
• Curl through hero_router returns 200 + JSON body for the patched URLs.
• No changes outside the two template files; no new dependencies.

Notes

• The fix relies on hero_router's /<svc>/ui/rpc[/...] -> rpc.sock rewrite (hero_router/src/server/routes.rs:1062-1106). For standalone ui.sock (no router in front), /openrpc.json was never reachable from the UI either way; that is out of scope for this fix.
• An alternative fully self-contained fix would be to add the hero_rpc_derive::openrpc_proxy! macro to hero_browser_ui (the pattern used by hero_proc_ui). That adds two git dependencies and a router merge; not pursued here because the one-line per-template fix is sufficient via the existing router shortcut.

## Implementation Spec for Issue #11 ### Objective Fix the broken `/openrpc.json` URL in two places in `hero_browser_ui` so it routes through hero_router's `ui/rpc[/...]` sibling shortcut, which forwards to `rpc.sock` where the spec is actually served. ### Requirements - **Item 1 (API Docs tab)**: tab loads the OpenRPC method documentation instead of the JSON-parse error. - **Item 2 (navbar OpenRPC button)**: button opens the spec instead of a 404 page. - No new dependencies, no router or backend changes — UI-only template edits. - Health-check item from the original report kept open pending repro details (UI/rpc.health/browser_list endpoints all return 200 from curl). ### Files to Modify - `crates/hero_browser_ui/templates/index.html` — change the `fetch()` URL in the API Docs tab loader. - `crates/hero_browser_ui/templates/base.html` — change the OpenRPC `<a href="">` in the navbar. ### Implementation Plan #### Step 1: Patch both template URLs Files: `crates/hero_browser_ui/templates/index.html`, `crates/hero_browser_ui/templates/base.html` - `index.html:180`: `fetch("{{ base_path }}/openrpc.json")` -> `fetch("{{ base_path }}/rpc/openrpc.json")` - `base.html:26`: `href="{{ base_path }}/openrpc.json"` -> `href="{{ base_path }}/rpc/openrpc.json"` Dependencies: none #### Step 2: Build and runtime-verify - `cargo build -p hero_browser_ui` (release) - Restart the `hero_browser_ui` action via `hero_proc` so the new templates take effect - `curl` both URLs through hero_router to confirm 200 + JSON body: - `GET /hero_browser/ui/rpc/openrpc.json` - `GET /hero_browser/rpc/openrpc.json` (control) Dependencies: Step 1 ### Acceptance Criteria - [ ] API Docs tab in the Browser app renders the accordion of method groups (no JSON parse error). - [ ] Navbar OpenRPC button opens the spec in a new tab. - [ ] `cargo build -p hero_browser_ui` succeeds. - [ ] Curl through hero_router returns 200 + JSON body for the patched URLs. - [ ] No changes outside the two template files; no new dependencies. ### Notes - The fix relies on hero_router's `/<svc>/ui/rpc[/...]` -> `rpc.sock` rewrite (`hero_router/src/server/routes.rs:1062-1106`). For standalone `ui.sock` (no router in front), `/openrpc.json` was never reachable from the UI either way; that is out of scope for this fix. - An alternative fully self-contained fix would be to add the `hero_rpc_derive::openrpc_proxy!` macro to `hero_browser_ui` (the pattern used by `hero_proc_ui`). That adds two git dependencies and a router merge; not pursued here because the one-line per-template fix is sufficient via the existing router shortcut.

salmaelsoly commented 2026-04-26 12:59:54 +00:00

Author

Member

Copy link

Implementation Summary (revised)

Three issues fixed on development_apidocs_fix, all in crates/hero_browser_ui/templates/:

A. API Docs tab (Item 1 in the report)

index.html:180 -- fetch URL changed:

- const resp = await fetch("{{ base_path }}/openrpc.json");
+ const resp = await fetch("{{ base_path }}/rpc/openrpc.json");

Same fix in base.html:26 for the navbar OpenRPC button.

B. Health-check failure (Item 2 in the report)

Root cause (different from A; surfaced via the request log shared on the issue):

GET /hero_browser/health
Referer: http://127.0.0.1:9151/hero_browser/ui

hero_router 308-redirects /hero_browser/ui/ -> /hero_browser/ui (strips trailing slash). With the document URL ending at .../ui (no slash), browser-relative URL resolution drops the last segment, so fetch("health") from connection-status.js:167 resolves to /hero_browser/health -- a non-route on hero_router -> 404 -> connection-status widget shows backend down.

The same trap silently affected fetch("rpc") in dashboard.js:7; that one happened to work only because hero_router also exposes the rpc proxy at the bare service-root /<svc>/rpc. Fragile, not load-bearing on intent.

Fix -- one line in base.html <head>:

+ <base href="{{ base_path }}/" />

All relative URLs the page issues (current health/rpc, plus anything any future JS adds) now resolve under the UI prefix regardless of trailing slash. No JS edits, no new dependencies.

C. Bonus: _server group label in the API Docs accordion

index.html:185-189 was using m.name.indexOf(".") and falling back to a literal group named "_server" for any method without a dot. Since most hero_browser methods are browser_*, page_*, element_* etc. (no dots), they all bucketed into one ugly group called _server.

- const dot = m.name.indexOf(".");
- const prefix = dot > 0 ? m.name.substring(0, dot) : "_server";
+ const match = m.name.match(/^([a-z0-9]+)[._]/);
+ const prefix = match ? match[1] : m.name;

Now groups become browser, page, element, js, viewport, network, console, cookies, dialog, accessibility, key, file, rpc -- one bucket per method family.

Diff stat

crates/hero_browser_ui/templates/base.html  | 3 ++-
crates/hero_browser_ui/templates/index.html | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)

No Rust changes, no new dependencies.

Build & runtime verification

• cargo build -p hero_browser_ui --release -- ok in ~7.5s (incremental).
• Service restarted via hero_proc; new PID; rpc.sock + ui.sock rebound.
• ~/hero/build/cargo/release cleaned post-build per local convention.

Curl-verified through hero_router:

URL	Result
GET /hero_browser/ui/rpc/openrpc.json	200 valid OpenRPC spec (was 404 at /hero_browser/ui/openrpc.json)
GET /hero_browser/ui/health	200 {"service":"hero_browser_ui","status":"ok","version":"0.1.0"}
POST /hero_browser/ui/rpc {rpc.health}	200 {"service":"hero_browser","status":"ok","version":"0.1.0"}
Rendered /hero_browser/ui/ <head>	now contains <base href="/hero_browser/ui/" />
GET /hero_browser/health (the URL that was failing)	still 404, but the page no longer issues this request

Acceptance criteria

• API Docs tab renders the accordion (and groups have meaningful names).
• Navbar OpenRPC button opens the spec.
• Connection-status widget's UI-health and backend-ping calls hit valid URLs.
• Build clean; only the two template files touched; no new dependencies.

Branch

development_apidocs_fix (no push, no PR per the workflow this skill follows).

## Implementation Summary (revised) Three issues fixed on `development_apidocs_fix`, all in `crates/hero_browser_ui/templates/`: ### A. API Docs tab (Item 1 in the report) `index.html:180` -- fetch URL changed: ```diff - const resp = await fetch("{{ base_path }}/openrpc.json"); + const resp = await fetch("{{ base_path }}/rpc/openrpc.json"); ``` Same fix in `base.html:26` for the navbar OpenRPC button. ### B. Health-check failure (Item 2 in the report) **Root cause** (different from A; surfaced via the request log shared on the issue): ``` GET /hero_browser/health Referer: http://127.0.0.1:9151/hero_browser/ui ``` hero_router 308-redirects `/hero_browser/ui/` -> `/hero_browser/ui` (strips trailing slash). With the document URL ending at `.../ui` (no slash), browser-relative URL resolution drops the last segment, so `fetch("health")` from `connection-status.js:167` resolves to `/hero_browser/health` -- a non-route on hero_router -> 404 -> connection-status widget shows backend down. The same trap silently affected `fetch("rpc")` in `dashboard.js:7`; that one happened to work only because hero_router *also* exposes the rpc proxy at the bare service-root `/<svc>/rpc`. Fragile, not load-bearing on intent. **Fix** -- one line in `base.html` `<head>`: ```diff + <base href="{{ base_path }}/" /> ``` All relative URLs the page issues (current `health`/`rpc`, plus anything any future JS adds) now resolve under the UI prefix regardless of trailing slash. No JS edits, no new dependencies. ### C. Bonus: `_server` group label in the API Docs accordion `index.html:185-189` was using `m.name.indexOf(".")` and falling back to a literal group named `"_server"` for any method without a dot. Since most hero_browser methods are `browser_*`, `page_*`, `element_*` etc. (no dots), they all bucketed into one ugly group called `_server`. ```diff - const dot = m.name.indexOf("."); - const prefix = dot > 0 ? m.name.substring(0, dot) : "_server"; + const match = m.name.match(/^([a-z0-9]+)[._]/); + const prefix = match ? match[1] : m.name; ``` Now groups become `browser`, `page`, `element`, `js`, `viewport`, `network`, `console`, `cookies`, `dialog`, `accessibility`, `key`, `file`, `rpc` -- one bucket per method family. ### Diff stat ``` crates/hero_browser_ui/templates/base.html | 3 ++- crates/hero_browser_ui/templates/index.html | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) ``` No Rust changes, no new dependencies. ### Build & runtime verification - `cargo build -p hero_browser_ui --release` -- ok in ~7.5s (incremental). - Service restarted via hero_proc; new PID; `rpc.sock` + `ui.sock` rebound. - `~/hero/build/cargo/release` cleaned post-build per local convention. Curl-verified through `hero_router`: | URL | Result | |---|---| | `GET /hero_browser/ui/rpc/openrpc.json` | `200` valid OpenRPC spec (was 404 at `/hero_browser/ui/openrpc.json`) | | `GET /hero_browser/ui/health` | `200` `{"service":"hero_browser_ui","status":"ok","version":"0.1.0"}` | | `POST /hero_browser/ui/rpc {rpc.health}` | `200` `{"service":"hero_browser","status":"ok","version":"0.1.0"}` | | Rendered `/hero_browser/ui/` `<head>` | now contains `<base href="/hero_browser/ui/" />` | | `GET /hero_browser/health` (the URL that was failing) | still 404, but the page no longer issues this request | ### Acceptance criteria - [x] API Docs tab renders the accordion (and groups have meaningful names). - [x] Navbar OpenRPC button opens the spec. - [x] Connection-status widget's UI-health and backend-ping calls hit valid URLs. - [x] Build clean; only the two template files touched; no new dependencies. ### Branch `development_apidocs_fix` (no push, no PR per the workflow this skill follows).

salmaelsoly referenced this issue from a pull request that will close it, 2026-04-26 13:03:09 +00:00

fix(browser_ui): /rpc shortcut, base href, group by _ #12

salmaelsoly closed this issue 2026-04-26 13:12:33 +00:00

salmaelsoly referenced this issue 2026-04-26 13:45:52 +00:00

Sessions/Activity panels empty: dashboard.js calls JSON-RPC methods that do not exist #13

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

main

latest

v0.1.0-rc1

v0.1.4-rc5

v0.1.3

v0.1.2

v0.1.1

v0.1.0

v0.0.1-rc1

Labels

Clear labels   

prio_critical

  

prio_low

  

type_bug

  

type_contact

  

type_issue

  

type_lead

  

type_question

  

type_story

  

type_task

No labels

prio_critical

prio_low

type_bug

type_contact

type_issue

type_lead

type_question

type_story

type_task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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_browser#11

No description provided.