lhumina_code/hero_blueprint

Fork 0

`OServer::run_cli` ignores `service.toml` socket paths — falls back to defaults #69

New issue

Closed

opened 2026-05-19 15:30:38 +00:00 by timur · 1 comment

timur commented

2026-05-19 15:30:38 +00:00

Owner

Context

Discovered by the #261 agent while bootstrapping hero_service.

The generated _server main.rs calls OServer::run_cli(lifecycle, ...) which is supposed to honor the socket path declared in the embedded service.toml. In practice it falls back to the default-derived path (HERO_SOCKET_DIR / service_name / rpc.sock), ignoring any custom path specified under [[binaries.sockets]].

For the standard case the result is fine (because the default matches the convention), but a service that legitimately needs a non-default socket path can't get it.

What to do

Trace OServer::run_cli socket resolution in hero_rpc/crates/server/.
Make it read the service.toml socket entry first and only fall back to the default if not set.
Add a test fixture with a non-default socket path and verify the server binds at the declared path.

Acceptance

Generated services with custom path in [[binaries.sockets]] bind at the declared path.
Default-case behaviour unchanged.

hero_skills#261.
Parent META: hero_skills#262.

## Context Discovered by the [#261 agent](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/261#issuecomment-34264) while bootstrapping `hero_service`. The generated `_server` `main.rs` calls `OServer::run_cli(lifecycle, ...)` which is supposed to honor the socket path declared in the embedded `service.toml`. In practice it falls back to the default-derived path (HERO_SOCKET_DIR / service_name / rpc.sock), ignoring any custom `path` specified under `[[binaries.sockets]]`. For the standard case the result is fine (because the default matches the convention), but a service that legitimately needs a non-default socket path can't get it. ## What to do - Trace `OServer::run_cli` socket resolution in `hero_rpc/crates/server/`. - Make it read the `service.toml` socket entry first and only fall back to the default if not set. - Add a test fixture with a non-default socket path and verify the server binds at the declared path. ## Acceptance - Generated services with custom `path` in `[[binaries.sockets]]` bind at the declared path. - Default-case behaviour unchanged. ## Related - [hero_skills#261](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/261). - Parent META: [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262).

timur referenced this issue from lhumina_code/hero_skills

2026-05-19 15:31:15 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262

timur referenced this issue from lhumina_code/hero_skills

2026-05-20 00:15:53 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262

timur referenced this issue from a commit

2026-05-20 00:18:28 +00:00

fix(server): honour service.toml rpc socket path in OServer::run_cli (#69)

timur referenced this issue from a commit

2026-05-20 00:21:13 +00:00

test(server): cover service.toml rpc socket override end-to-end (#69)

timur referenced this issue from a commit

2026-05-20 00:24:30 +00:00

chore(example): opt recipe_server into service.toml rpc path resolution (#69)

timur commented

2026-05-20 00:24:50 +00:00

Author

Owner

Fix on `issue-69-oserver-socket-paths`

Three commits (compare):

fix(server) — 8617118 — core fix.
test(server) — 17687b6 — integration test in crates/server/tests/run_cli_socket_path.rs.
chore(example) — 564c4de — opt the recipe_server example into the new resolution.

Root cause

OServer::run_cli constructed an OServerConfig only with the lifecycle's service_name and bound at config.rpc_socket(&config.name) → $HERO_SOCKET_DIR/<service_name>/rpc.sock. It never read service.toml, so a binary like petstore_server declaring path = "hero_petstore/rpc.sock" was silently bound at petstore_server/rpc.sock instead.

print_info_json had the same bug — the --info JSON descriptor reported the default path, not the declared one.

Fix

New HeroLifecycle::service_toml(toml_str) builder — attach the embedded manifest to the lifecycle.
New OServerConfig::rpc_socket_relative(rel) builder — override the rpc socket path.
OServer::run_cli now parses the attached service.toml, finds the rpc socket entry (SockType::Rpc) for the matching binary, and propagates path as the override. Falls back gracefully when no manifest is attached or no rpc socket is declared.
print_info_json uses the same resolution.
Resolution is fully unit-tested in crates/server/src/server/server.rs and end-to-end in the new integration test.

Acceptance

✅ Generated services with custom path in [[binaries.sockets]] bind at the declared path (validated by rpc_socket_path_resolution::Case 1, plus a live rpc.health request).
✅ Default-case behaviour unchanged (validated by rpc_socket_path_resolution::Case 2).
✅ All existing tests pass (cargo test -p hero_rpc_server -p hero_lifecycle: 21 + 8 + 1 + doctests, all green).

### Fix on `issue-69-oserver-socket-paths` Three commits ([compare](https://forge.ourworld.tf/lhumina_code/hero_rpc/compare/development...issue-69-oserver-socket-paths)): 1. **`fix(server)`** — `8617118` — core fix. 2. **`test(server)`** — `17687b6` — integration test in `crates/server/tests/run_cli_socket_path.rs`. 3. **`chore(example)`** — `564c4de` — opt the `recipe_server` example into the new resolution. ### Root cause `OServer::run_cli` constructed an `OServerConfig` only with the lifecycle's `service_name` and bound at `config.rpc_socket(&config.name)` → `$HERO_SOCKET_DIR/<service_name>/rpc.sock`. It never read `service.toml`, so a binary like `petstore_server` declaring `path = "hero_petstore/rpc.sock"` was silently bound at `petstore_server/rpc.sock` instead. `print_info_json` had the same bug — the `--info` JSON descriptor reported the default path, not the declared one. ### Fix - New `HeroLifecycle::service_toml(toml_str)` builder — attach the embedded manifest to the lifecycle. - New `OServerConfig::rpc_socket_relative(rel)` builder — override the rpc socket path. - `OServer::run_cli` now parses the attached `service.toml`, finds the rpc socket entry (`SockType::Rpc`) for the matching binary, and propagates `path` as the override. Falls back gracefully when no manifest is attached or no rpc socket is declared. - `print_info_json` uses the same resolution. - Resolution is fully unit-tested in `crates/server/src/server/server.rs` and end-to-end in the new integration test. ### Acceptance - ✅ Generated services with custom `path` in `[[binaries.sockets]]` bind at the declared path (validated by `rpc_socket_path_resolution::Case 1`, plus a live `rpc.health` request). - ✅ Default-case behaviour unchanged (validated by `rpc_socket_path_resolution::Case 2`). - ✅ All existing tests pass (`cargo test -p hero_rpc_server -p hero_lifecycle`: 21 + 8 + 1 + doctests, all green).

timur referenced this issue from a pull request that will close it,

2026-05-20 05:55:04 +00:00

Fix OServer::run_cli to honor service.toml socket paths (#69) #79

timur referenced this issue from a commit

2026-05-20 05:55:08 +00:00

Fix OServer::run_cli to honor service.toml socket paths (#69) (#79)

timur closed this issue

2026-05-20 05:55:09 +00:00

timur referenced this issue from lhumina_code/hero_skills

2026-05-20 05:57:18 +00:00

[META] Standardize Hero service architecture — template, hero_rpc alignment, framework hoist, skills #262