fix: bind RESP TCP on HERO_DB_PORT (default 6378) and serve admin UI on ui.sock #36

nabil_salah · 2026-06-02T12:14:18Z

nabil_salah commented

2026-06-02 12:14:18 +00:00

Part of the production-readiness pass for hero_db (lhumina_code/home repos_focus_production.md). Two defects found by actually building + running hero_db under hero_proc.

1. RESP TCP port hardcoded to 6379

hero_db_server had let port = "6379".parse().unwrap_or(6378); — a leftover from a "simplified parse expression" commit. It ignored HERO_DB_PORT and bound 6379, contradicting the documented default 6378 used by the SDK, integration tests, the kill_other entry, the startup banner, and all docs. Restored the env-var read defaulting to 6378. Also fixed the INFO command, which hardcoded tcp_port:6379.

2. Admin dashboard unreachable via hero_router

hero_db_admin bound its dashboard on admin.sock, but hero_router proxies a service's web UI at /<service>/ui/ via a socket named ui.sock. So the dashboard was unreachable through the router — even though README.md already documented http://localhost:9988/hero_db/ui/. Renamed the socket to ui.sock in service.toml (the manifest the hero_admin_server!() macro reads), the kill_other entry, AdminConfig, and docs (CLAUDE.md / README / PURPOSE).

Verification

cargo check --workspace clean; cargo test --workspace --lib --bins → 41 passed.
Release-built + installed via lab build --release --workspace --install.
Running under hero_proc: server listens on :6378, INFO reports tcp_port:6378, RESP ping/set/get work, and the dashboard loads (HTTP 200) at /hero_db/ui/ through hero_router with a real ui.sock.

Notes / not included

Did not touch Cargo.toml rust-version (lab policy-apply flips 1.96↔1.95.0; left it for a separate decision) or commit .hero/* build artifacts.
Pre-existing, out of scope: INFO still reports a stale hero_db_version:0.2.0; startup warns resp.sock — already bound by another process (appears even on a clean start).

Part of the production-readiness pass for hero_db (lhumina_code/home repos_focus_production.md). Two defects found by actually building + running hero_db under hero_proc. ## 1. RESP TCP port hardcoded to 6379 `hero_db_server` had `let port = "6379".parse().unwrap_or(6378);` — a leftover from a "simplified parse expression" commit. It ignored `HERO_DB_PORT` and bound 6379, contradicting the documented default **6378** used by the SDK, integration tests, the `kill_other` entry, the startup banner, and all docs. Restored the env-var read defaulting to 6378. Also fixed the `INFO` command, which hardcoded `tcp_port:6379`. ## 2. Admin dashboard unreachable via hero_router `hero_db_admin` bound its dashboard on `admin.sock`, but hero_router proxies a service's web UI at `/<service>/ui/` via a socket named `ui.sock`. So the dashboard was unreachable through the router — even though `README.md` already documented `http://localhost:9988/hero_db/ui/`. Renamed the socket to `ui.sock` in `service.toml` (the manifest the `hero_admin_server!()` macro reads), the `kill_other` entry, `AdminConfig`, and docs (CLAUDE.md / README / PURPOSE). ## Verification - `cargo check --workspace` clean; `cargo test --workspace --lib --bins` → 41 passed. - Release-built + installed via `lab build --release --workspace --install`. - Running under hero_proc: server listens on `:6378`, `INFO` reports `tcp_port:6378`, RESP `ping`/`set`/`get` work, and the dashboard loads (HTTP 200) at `/hero_db/ui/` through hero_router with a real `ui.sock`. ## Notes / not included - Did **not** touch `Cargo.toml` `rust-version` (lab policy-apply flips 1.96↔1.95.0; left it for a separate decision) or commit `.hero/*` build artifacts. - Pre-existing, out of scope: `INFO` still reports a stale `hero_db_version:0.2.0`; startup warns `resp.sock — already bound by another process` (appears even on a clean start).

nabil_salah added 1 commit

2026-06-02 12:14:18 +00:00

fix: bind RESP TCP on HERO_DB_PORT (default 6378) and serve admin UI on ui.sock

Build and Test / build (pull_request) Failing after 36s

Details

87b3edbe31

Two defects surfaced by running hero_db under hero_proc:

Port: hero_db_server hardcoded the RESP TCP port to 6379 (leftover from a
"simplified" parse expression), ignoring HERO_DB_PORT and contradicting the
documented default 6378 used by the SDK, integration tests, the kill_other
entry, and all docs. Restore the env-var read defaulting to 6378, and fix
the INFO command which likewise hardcoded tcp_port:6379.

Admin UI: hero_db_admin bound its dashboard on admin.sock, but hero_router
proxies a service web UI at /<service>/ui/ via a socket named ui.sock, so
the dashboard was unreachable through the router (README already documented
http://localhost:9988/hero_db/ui/). Rename the admin socket to ui.sock in
service.toml, the kill_other entry, AdminConfig, and the docs.

Verified locally: server listens on :6378, INFO reports 6378, RESP
ping/set/get work, and the dashboard loads at /hero_db/ui/ via hero_router.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

nabil_salah commented

2026-06-02 12:15:40 +00:00

it now works fine

it now works fine ![image](/attachments/bcf649cf-99d2-4bd9-b8bd-a469167176c6)

image.png

108 KiB

mahmoud reviewed

2026-06-02 12:26:29 +00:00

CLAUDE.md

					
				@ -23,3 +23,3 @@

				├── rpc.sock HTTP/1.1 OpenRPC JSON-RPC 2.0 management (hero_db_server)

				├── resp.sock RESP2 Redis wire protocol via Unix socket (hero_db_server)

				└── admin.sock HTTP/1.1 Admin HTML dashboard (hero_db_admin)

				└── ui.sock HTTP/1.1 Admin HTML dashboard (hero_db_admin)

I am not sure about this change, I think we changed this _ui prefix to _admin, Kristof merged dev to main this morning, so I suppose it has the new _admin prefix, no?

@mahmoud wrote in #36 (comment):

I am not sure about this change, I think we changed this _ui prefix to _admin, Kristof merged dev to main this morning, so I suppose it has the new _admin prefix, no?

it didn't work with admin sock from hero_proc side, it was expecting ui sock.

@mahmoud wrote in https://forge.ourworld.tf/lhumina_code/hero_db/pulls/36#issuecomment-38191: > I am not sure about this change, I think we changed this _ui prefix to _admin, Kristof merged dev to main this morning, so I suppose it has the new _admin prefix, no? it didn't work with admin sock from hero_proc side, it was expecting ui sock.

nabil_salah referenced this pull request

2026-06-02 13:25:12 +00:00

fix: bind RESP TCP on HERO_DB_PORT (default 6378) instead of hardcoded 6379 #37

nabil_salah commented

2026-06-02 13:25:35 +00:00

Superseded by #37. The admin.sock→ui.sock rename here turned out unnecessary: it was an artifact of testing against a stale hero_router (0.2.1). Verified against the latest hero_proc 0.6.0 + hero_router that the original admin.sock is served correctly at /hero_db/admin/ (the ecosystem standardized on admin.sock in hero_proc 8f28cd4). #37 keeps only the real fix — the RESP TCP port (HERO_DB_PORT, default 6378).

Superseded by #37. The admin.sock→ui.sock rename here turned out unnecessary: it was an artifact of testing against a stale hero_router (0.2.1). Verified against the latest hero_proc 0.6.0 + hero_router that the original `admin.sock` is served correctly at `/hero_db/admin/` (the ecosystem standardized on admin.sock in hero_proc 8f28cd4). #37 keeps only the real fix — the RESP TCP port (HERO_DB_PORT, default 6378).

nabil_salah closed this pull request

2026-06-02 13:25:36 +00:00