fix: bind RESP TCP on HERO_DB_PORT (default 6378) instead of hardcoded 6379 #37
No reviewers
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_db!37
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/resp-tcp-port-6378"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
hero_db_serverhardcoded the RESP TCP port as"6379".parse().unwrap_or(6378)(a leftover from a "simplified port parse expression" refactor), so it ignoredHERO_DB_PORTand bound 6379 — contradicting the documented default 6378 used everywhere else: the help text, the SDK, integration tests, thekill_otherentry,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 theINFOcommand, which separately hardcodedtcp_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 originaladmin.sockis served correctly at/hero_db/admin/(the new router prefersadmin.sockand also accepts/ui/). The ecosystem standardized onadmin.sock(hero_proc renamedui.sock→admin.sockin 8f28cd4), so hero_db's existingadmin.sockis already correct. This PR therefore contains only the port fix and supersedes #36.Verification
Against the latest stack: server listens on
:6378,INFOreports6378, RESPping/set/getwork, and the admin dashboard loads (HTTP 200) at/hero_db/admin/via hero_router.48977773819dceae40eePlease merge after green CI