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

Merged
nabil_salah merged 3 commits from fix/resp-tcp-port-6378 into main 2026-06-03 11:32:00 +00:00
Member

Problem

hero_db_server hardcoded the RESP TCP port as "6379".parse().unwrap_or(6378) (a leftover from a "simplified port parse expression" refactor), so it ignored HERO_DB_PORT and bound 6379 — contradicting the documented default 6378 used everywhere else: the help text, the SDK, integration tests, the kill_other entry, service.toml's [[binaries.tcp]] port = 6378, and the startup banner (which already printed 6378 from config while the listener bound 6379).

Fix

Read HERO_DB_PORT, defaulting to 6378. Also fixes the INFO command, which separately hardcoded tcp_port:6379.

Why no socket change

An earlier draft (#36) also renamed admin.sockui.sock, but that was an artifact of testing against a stale hero_router (0.2.1). Verified against the latest hero_proc 0.6.0 + hero_router: the original admin.sock is served correctly at /hero_db/admin/ (the new router prefers admin.sock and also accepts /ui/). The ecosystem standardized on admin.sock (hero_proc renamed ui.sockadmin.sock in 8f28cd4), so hero_db's existing admin.sock is already correct. This PR therefore contains only the port fix and supersedes #36.

Verification

Against the latest stack: server listens on :6378, INFO reports 6378, RESP ping/set/get work, and the admin dashboard loads (HTTP 200) at /hero_db/admin/ via hero_router.

## Problem `hero_db_server` hardcoded the RESP TCP port as `"6379".parse().unwrap_or(6378)` (a leftover from a "simplified port parse expression" refactor), so it ignored `HERO_DB_PORT` and bound **6379** — contradicting the documented default **6378** used everywhere else: the help text, the SDK, integration tests, the `kill_other` entry, `service.toml`'s `[[binaries.tcp]] port = 6378`, and the startup banner (which already printed 6378 from config while the listener bound 6379). ## Fix Read `HERO_DB_PORT`, defaulting to 6378. Also fixes the `INFO` command, which separately hardcoded `tcp_port:6379`. ## Why no socket change An earlier draft (#36) also renamed `admin.sock` → `ui.sock`, but that was an artifact of testing against a stale hero_router (0.2.1). Verified against the **latest** hero_proc 0.6.0 + hero_router: the original `admin.sock` is served correctly at `/hero_db/admin/` (the new router prefers `admin.sock` and also accepts `/ui/`). The ecosystem standardized on `admin.sock` (hero_proc renamed `ui.sock`→`admin.sock` in 8f28cd4), so hero_db's existing `admin.sock` is already correct. This PR therefore contains **only the port fix** and supersedes #36. ## Verification Against the latest stack: server listens on `:6378`, `INFO` reports `6378`, RESP `ping/set/get` work, and the admin dashboard loads (HTTP 200) at `/hero_db/admin/` via hero_router.
fix: bind RESP TCP on HERO_DB_PORT (default 6378) instead of hardcoded 6379
Some checks failed
Build and Test / build (pull_request) Failing after 37s
4897777381
hero_db_server hardcoded the RESP TCP port as `"6379".parse().unwrap_or(6378)`
— a leftover from a "simplified port parse expression" refactor — so it ignored
HERO_DB_PORT and bound 6379. That contradicts the documented default of 6378
used everywhere else: the help text, the SDK, integration tests, the kill_other
entry, service.toml's `[[binaries.tcp]] port = 6378`, and the startup banner
(which already printed 6378 from config while the listener bound 6379). Read
HERO_DB_PORT, defaulting to 6378. Also fix the INFO command, which separately
hardcoded `tcp_port:6379`.

Verified against the latest hero_proc/hero_router stack: server listens on
:6378, INFO reports 6378, RESP ping/set/get work, and the admin dashboard is
reachable via hero_router at /hero_db/admin/ (admin.sock unchanged).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
nabil_salah changed target branch from development to main 2026-06-02 13:28:38 +00:00
nabil_salah force-pushed fix/resp-tcp-port-6378 from 4897777381
Some checks failed
Build and Test / build (pull_request) Failing after 37s
to 9dceae40ee
Some checks failed
Build and Test / build (pull_request) Failing after 3m12s
2026-06-02 14:42:05 +00:00
Compare
mahmoud approved these changes 2026-06-02 15:12:42 +00:00
Owner

Please merge after green CI

Please merge after green CI
ci: install sccache in the build-and-test job
Some checks failed
Build and Test / build (pull_request) Failing after 11m56s
7a8471d828
build.yaml runs raw `cargo` (check/test/build), which reads the workspace
`.cargo/config.toml` `rustc-wrapper = "sccache"` and fails because the builder
image (ghcr.io/despiegk/builder) doesn't ship sccache:
"could not execute process `sccache ... rustc -vV` ... No such file or directory".

Install sccache via cargo before the cargo steps. The install runs from /tmp,
outside the repo, so the workspace config does not apply during it (otherwise
cargo would try to use sccache to compile sccache — chicken-and-egg).
lab-publish is unaffected; `lab build` manages sccache itself.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ci: authenticate private forge git deps in build-and-test
All checks were successful
Build and Test / build (pull_request) Successful in 34m47s
a34f13159d
cargo check/build fetch private git deps from forge.ourworld.tf
(hero_lib, hero_admin_lib -> hero_theme), but the build-and-test job had no
credentials so the fetch failed. Authenticate with the FORGE_TOKEN secret
(git credential store + net.git-fetch-with-cli), and rewrite the renamed
hero_web_template repo so the locked hero_theme rev resolves — its 301 isn't
followed by git fetch's smart-HTTP RPC.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
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_db!37
No description provided.