Admin UI service discovery fails on the renamed router binary and the fixed 9988 bind

mik-tf commented

2026-06-23 15:19:02 +00:00

Owner

The shared admin UI (hero_components) lists services by calling the router's own list method at /api/services/rpc. The router binary was renamed from hero_router to hero_router_server, and only the new hero_router_server serves that endpoint. Any environment still running the old hero_router binary answers that call with Socket 'web_services.sock' not found for 'api', so the admin UI cannot enumerate services and every service pane (biz, planner, kimi) fails to load, even though the per-service domain calls at /<service>/rpc/api/{domain}/rpc work fine when hit directly.

A second problem shows up when trying to run the new binary for local verification: hero_router_server also binds TCP 127.0.0.1:9988 (its UI host default) regardless of the --bind ADDR:PORT value, so a second instance cannot start alongside an existing router and fails with Address already in use. Could you confirm hero_router_server is the canonical binary going forward and is published and installed everywhere, and make the TCP bind honor --bind so a second instance can run on another port for testing? This currently blocks the in-browser verification of the Dioxus admin panes tracked in lhumina_code/home_lhumina#309 . Happy to test once it lands.

Signed-by: mik-tf mik-tf@noreply.invalid

The shared admin UI (`hero_components`) lists services by calling the router's own `list` method at `/api/services/rpc`. The router binary was renamed from `hero_router` to `hero_router_server`, and only the new `hero_router_server` serves that endpoint. Any environment still running the old `hero_router` binary answers that call with `Socket 'web_services.sock' not found for 'api'`, so the admin UI cannot enumerate services and every service pane (biz, planner, kimi) fails to load, even though the per-service domain calls at `/<service>/rpc/api/{domain}/rpc` work fine when hit directly. A second problem shows up when trying to run the new binary for local verification: `hero_router_server` also binds TCP `127.0.0.1:9988` (its UI host default) regardless of the `--bind ADDR:PORT` value, so a second instance cannot start alongside an existing router and fails with `Address already in use`. Could you confirm `hero_router_server` is the canonical binary going forward and is published and installed everywhere, and make the TCP bind honor `--bind` so a second instance can run on another port for testing? This currently blocks the in-browser verification of the Dioxus admin panes tracked in https://forge.ourworld.tf/lhumina_code/home_lhumina/issues/309 . Happy to test once it lands. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf referenced this issue from lhumina_code/home_lhumina

2026-06-23 15:19:34 +00:00

[platform] migration of repo's on development trunk on the Hero Platform #309

mik-tf referenced this issue from lhumina_code/home_lhumina

2026-06-23 15:36:19 +00:00

[platform] migration of repo's on development trunk on the Hero Platform #309

despiegk commented

2026-06-23 18:30:14 +00:00

Owner

we don't want things like --bind ADDR:PORT

there should not be 2 routers running

its now like any _serversame code path

in general no separate paths for testing please, messes up everything sockets, tcp ports

we don't want things like --bind ADDR:PORT there should not be 2 routers running its now like any _serversame code path in general no separate paths for testing please, messes up everything sockets, tcp ports

mik-tf commented

2026-06-23 18:43:29 +00:00

Author

Owner

Thanks, that settles it. Confirmed hero_router_server is the canonical binary (same _server convention and code path as every other service), and we will not add a bind flag or run a second router on another port. The admin UI discovery failure only happened where the old hero_router binary was still running, so the fix is purely on the install side: start hero_router_server and never the old hero_router. I will update the installer accordingly and drop the stale hero_router asset so it stops being pulled in. Closing as resolved.

Signed-by: mik-tf mik-tf@noreply.invalid

Thanks, that settles it. Confirmed hero_router_server is the canonical binary (same _server convention and code path as every other service), and we will not add a bind flag or run a second router on another port. The admin UI discovery failure only happened where the old hero_router binary was still running, so the fix is purely on the install side: start hero_router_server and never the old hero_router. I will update the installer accordingly and drop the stale hero_router asset so it stops being pulled in. Closing as resolved. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf closed this issue

2026-06-23 18:43:29 +00:00

Rows
Columns

Admin UI service discovery fails on the renamed router binary and the fixed 9988 bind #126