rpc surface not migrated to canonical hero_sockets routes (legacy-only) #51

Closed
opened 2026-06-16 11:45:10 +00:00 by mahmoud · 3 comments
Owner

Summary

hero_livekit's rpc socket has not been migrated to the canonical hero_sockets.md route surface. It hand-rolls only the legacy / pre-migration endpoints (/health, /.well-known/heroservice.json, /rpc, /openrpc.json) and serves none of the canonical endpoints, so hero_router's Diagnostics → Spec compliance probe reports it Non-compliant.

Canonical surface required (hero_sockets.md)

On rpc.sock:

  • GET /health.json
  • GET /heroservice.json
  • GET /api/domains.json
  • GET /api/ping"pong"
  • GET /api/{domain}/openrpc.json
  • POST /api/{domain}/rpc

Current state

Serves only the legacy set (/health, /.well-known/heroservice.json, /rpc, /openrpc.json); all canonical paths return 404.
Hand-rolled router: crates/hero_livekit_backend/src/main.rs.

curl --unix-socket ~/hero/var/sockets/hero_livekit/rpc.sock http://localhost/health.json   # → 404 (expect 200)
curl --unix-socket ~/hero/var/sockets/hero_livekit/rpc.sock http://localhost/api/ping       # → 404 (expect 200 "pong")

Fix

Stop hand-rolling the rpc surface; mount the shared hero_lib canonical router so the full surface (incl. /api/ping) comes for free and can't drift:

  • hero_lifecycle::rpc::mandatory_router(...) / service_root_router(...), or
  • the generated oschema_server build_router(...).

Compliant services (hero_proc, hero_code, hero_router) already do this. hero_browser was the minimal-fix counter-example (commit c6f5abe just added the missing /api/ping); a full migration is preferred here since the whole surface is absent.

Verify

Each canonical path returns 200 over the rpc socket, and the service's Diagnostics tab in hero_router reports compliant (required_fail: 0).

## Summary `hero_livekit`'s rpc socket has **not been migrated to the canonical `hero_sockets.md` route surface**. It hand-rolls only the legacy / pre-migration endpoints (`/health`, `/.well-known/heroservice.json`, `/rpc`, `/openrpc.json`) and serves **none** of the canonical endpoints, so hero_router's **Diagnostics → Spec compliance probe** reports it Non-compliant. ## Canonical surface required (`hero_sockets.md`) On `rpc.sock`: - `GET /health.json` - `GET /heroservice.json` - `GET /api/domains.json` - `GET /api/ping` → `"pong"` - `GET /api/{domain}/openrpc.json` - `POST /api/{domain}/rpc` ## Current state Serves only the legacy set (`/health`, `/.well-known/heroservice.json`, `/rpc`, `/openrpc.json`); all canonical paths return `404`. Hand-rolled router: `crates/hero_livekit_backend/src/main.rs`. ```bash curl --unix-socket ~/hero/var/sockets/hero_livekit/rpc.sock http://localhost/health.json # → 404 (expect 200) curl --unix-socket ~/hero/var/sockets/hero_livekit/rpc.sock http://localhost/api/ping # → 404 (expect 200 "pong") ``` ## Fix Stop hand-rolling the rpc surface; mount the shared hero_lib canonical router so the full surface (incl. `/api/ping`) comes for free and can't drift: - `hero_lifecycle::rpc::mandatory_router(...)` / `service_root_router(...)`, or - the generated `oschema_server` `build_router(...)`. Compliant services (hero_proc, hero_code, hero_router) already do this. hero_browser was the minimal-fix counter-example (commit `c6f5abe` just added the missing `/api/ping`); a full migration is preferred here since the whole surface is absent. ## Verify Each canonical path returns `200` over the rpc socket, and the service's **Diagnostics** tab in hero_router reports compliant (`required_fail: 0`).
Member

Coordination: I am taking the full hero_livekit canonical-surface migration on development (decided with Sameh). It resolves this issue (server surface → canonical router) and the connectivity half of #50 (client calls to hero_proc move off the dead legacy /rpc to /api/secrets/rpc). The two are the same root cause (hero_livekit still on the frozen pre-migration stack), so a single migration covers both.

Sequencing: queued right after I close out some in-flight hero_collab issues; starting on it next. @mahmoud — to avoid duplicate work, are you mid-implementation on this? If so let's split/coordinate; otherwise I'll own it and credit your diagnosis here. Your "mount the shared canonical router / oschema_server" direction is exactly the plan.

**Coordination:** I am taking the full hero_livekit canonical-surface migration on `development` (decided with Sameh). It resolves this issue (server surface → canonical router) **and** the connectivity half of #50 (client calls to hero_proc move off the dead legacy `/rpc` to `/api/secrets/rpc`). The two are the same root cause (hero_livekit still on the frozen pre-migration stack), so a single migration covers both. Sequencing: queued right after I close out some in-flight hero_collab issues; starting on it next. @mahmoud — to avoid duplicate work, are you mid-implementation on this? If so let's split/coordinate; otherwise I'll own it and credit your diagnosis here. Your "mount the shared canonical router / oschema_server" direction is exactly the plan.
Member

Migration plan written (turnkey): hero_livekit/docs/superpowers/plans/2026-06-16-livekit-canonical-migration.md on branch development_sameh_livekit_migration. Target = canonical herolib serving (herolib_macros::openrpc_server! + serve_domains), like hero_collab/hero_proc — NOT the stale livekit_migration hero_rpc approach. The oschema already has a service LiveKitService { } block (close to the collab pattern). Remaining: deps flip (osis_oldserving→herolib@development), main.rs rewrite (drop rpc2_adapter/OsisLivekit), provision port (fold #50 hardening from development_sameh_livekit50 f30c9b6), SDK/admin canonical updates, box verify. SFU runs meanwhile via manual LiveKitService.start (survives until hero_livekit_server restart). Collab regression sweep (the blocker) is DONE+merged; livekit migration is the focused next push.

**Migration plan written** (turnkey): `hero_livekit/docs/superpowers/plans/2026-06-16-livekit-canonical-migration.md` on branch `development_sameh_livekit_migration`. Target = canonical **herolib** serving (`herolib_macros::openrpc_server!` + serve_domains), like hero_collab/hero_proc — NOT the stale `livekit_migration` hero_rpc approach. The oschema already has a `service LiveKitService { }` block (close to the collab pattern). Remaining: deps flip (osis_oldserving→herolib@development), main.rs rewrite (drop rpc2_adapter/OsisLivekit), provision port (fold #50 hardening from `development_sameh_livekit50` f30c9b6), SDK/admin canonical updates, box verify. SFU runs meanwhile via manual `LiveKitService.start` (survives until hero_livekit_server restart). Collab regression sweep (the blocker) is DONE+merged; livekit migration is the focused next push.
Member

Fixed + closed in 63f80f5 (development) — hero_livekit migrated off the frozen osis_oldserving (hero_rpc2/OSIS) stack to the canonical herolib serving (herolib_macros::openrpc_server! + serve_domains), like hero_collab/hero_proc.

It now serves the full canonical hero_sockets surface on rpc.sock; legacy /rpc is gone (404).

Verified on box: GET /api/ping"pong"; GET /api/domains.json{main}; GET /heroservice.json → 200; POST /api/main/rpc (bare method names, e.g. status) works; and the hero_router dashboard discovers the service with its 12-method surface (Diagnostics no longer legacy-only). Thanks @mahmoud for the diagnosis.

**Fixed + closed** in `63f80f5` (development) — hero_livekit migrated off the frozen `osis_oldserving` (hero_rpc2/OSIS) stack to the canonical **herolib** serving (`herolib_macros::openrpc_server!` + `serve_domains`), like hero_collab/hero_proc. It now serves the full canonical hero_sockets surface on rpc.sock; legacy `/rpc` is gone (404). **Verified on box:** `GET /api/ping` → `"pong"`; `GET /api/domains.json` → `{main}`; `GET /heroservice.json` → 200; `POST /api/main/rpc` (bare method names, e.g. `status`) works; and the **hero_router dashboard discovers the service with its 12-method surface** (Diagnostics no longer legacy-only). Thanks @mahmoud for the diagnosis.
Sign in to join this conversation.
No labels
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_livekit#51
No description provided.