lhumina_code/hero_skills
4
0
Fork 0
Code Issues 34 Pull requests Projects Releases 1 Packages 1 Wiki Activity Actions

feat(service_livekit): forward-compat with hero_livekit configure RPC #174

Closed
sameh-farouk wants to merge 0 commits from feat/livekit-per-user-ports-compat into development
pull from: feat/livekit-per-user-ports-compat
merge into: lhumina_code:development
Conversation 1 Commits - Files changed - +6
sameh-farouk commented 2026-04-30 01:14:12 +00:00
Member
Copy link

Closes #173. Companion to hero_livekit#34.

Summary

Single change: adds rtc_tcp_port: 0 to cfg_params in service_livekit.nu. Required because hero_livekit#34 extends the livekitservice.configure RPC with a new mandatory rtc_tcp_port parameter. Without this, every service_livekit start against the new wrapper fails with "Missing required parameter: rtc_tcp_port".

0 = "keep current value" follows the same convention as livekit_port and backend_port already use.

Scope kept narrow on purpose

An earlier draft of this PR also modified svx_lk_wipe_stale_configs to preserve runtime.json across wipes, with the goal of making per-user values durable. That was the wrong layer to fix it:

  • runtime.json is a derived cache; the wipe correctly forces a clean slate on inconsistency
  • The right durable source for per-user values is hero_cfg.toml, where [mycelium] already lives
  • The next service_livekit start after a wipe should re-read hero_cfg.toml and re-derive runtime.json from there

That reconstruction logic is in the follow-up PR (PR-2): service_livekit.nu reads [livekit] section from hero_cfg.toml and passes those values to the configure RPC. The wipe stays as-is.

Compatibility matrix

service_livekit.nu hero_livekit binary configure RPC works?
old (no rtc_tcp_port) old ✓
old (no rtc_tcp_port) new (#34) ✗ "Missing required parameter"
new (this PR, rtc_tcp_port:0) old ✓ extra field ignored
new (this PR, rtc_tcp_port:0) new (#34) ✓

Land this PR at-or-before the hero_livekit binary is upgraded on operator boxes.

Test plan

  • service_livekit start against an old wrapper still works (extra rtc_tcp_port: 0 field ignored by old serde)
  • service_livekit start against a new wrapper (hero_livekit#34) works (configure RPC accepts the field)

Follow-up

PR-2: read [livekit] section from hero_cfg.toml and pass values into cfg_params instead of hardcoded 0. That closes the loop on automatic per-user port allocation without touching the wipe behavior.

Closes #173. Companion to [hero_livekit#34](https://forge.ourworld.tf/lhumina_code/hero_livekit/pulls/34). ## Summary Single change: adds `rtc_tcp_port: 0` to `cfg_params` in `service_livekit.nu`. Required because hero_livekit#34 extends the `livekitservice.configure` RPC with a new mandatory `rtc_tcp_port` parameter. Without this, every `service_livekit start` against the new wrapper fails with `"Missing required parameter: rtc_tcp_port"`. `0 = "keep current value"` follows the same convention as `livekit_port` and `backend_port` already use. ## Scope kept narrow on purpose An earlier draft of this PR also modified `svx_lk_wipe_stale_configs` to preserve `runtime.json` across wipes, with the goal of making per-user values durable. That was the **wrong layer** to fix it: - `runtime.json` is a derived cache; the wipe correctly forces a clean slate on inconsistency - The right durable source for per-user values is `hero_cfg.toml`, where `[mycelium]` already lives - The next `service_livekit start` after a wipe should re-read `hero_cfg.toml` and re-derive `runtime.json` from there That reconstruction logic is in the **follow-up PR** (PR-2): service_livekit.nu reads `[livekit]` section from `hero_cfg.toml` and passes those values to the configure RPC. The wipe stays as-is. ## Compatibility matrix | service_livekit.nu | hero_livekit binary | configure RPC works? | |---|---|---| | old (no rtc_tcp_port) | old | ✓ | | old (no rtc_tcp_port) | new (#34) | ✗ "Missing required parameter" | | **new (this PR, rtc_tcp_port:0)** | old | ✓ extra field ignored | | **new (this PR, rtc_tcp_port:0)** | new (#34) | ✓ | Land this PR at-or-before the hero_livekit binary is upgraded on operator boxes. ## Test plan - [x] `service_livekit start` against an old wrapper still works (extra `rtc_tcp_port: 0` field ignored by old serde) - [x] `service_livekit start` against a new wrapper (hero_livekit#34) works (configure RPC accepts the field) ## Follow-up PR-2: read `[livekit]` section from `hero_cfg.toml` and pass values into `cfg_params` instead of hardcoded 0. That closes the loop on automatic per-user port allocation without touching the wipe behavior.
feat(service_livekit): forward-compat with hero_livekit per-user-port PR + preserve runtime.json on wipe
All checks were successful
Build and Publish Skills / build-and-publish (pull_request) Successful in 4s
Details
eb0825464f 
Two changes, both small, that together let multi-user setups use
service_livekit start without the manual curl-bypass workaround:

(A) Add rtc_tcp_port: 0 to cfg_params

After hero_livekit PR #34 lands, the configure RPC requires
rtc_tcp_port as a named param. service_livekit start would fail with
"Missing required parameter: rtc_tcp_port" otherwise. We pass 0 to
preserve current behavior (0 means "keep existing value", same
convention as livekit_port/backend_port).

This is forward- and backward-compatible:
  - Old wrapper + new service_livekit.nu: extra field ignored, OK
  - New wrapper + new service_livekit.nu: field used, OK
  - New wrapper + OLD service_livekit.nu: BREAKS (missing param)

So this commit must land at or before the hero_livekit binary
upgrade reaches operator boxes.

(B) svx_lk_wipe_stale_configs preserves runtime.json

Previously the wipe deleted runtime.json alongside livekit.yaml +
backend.env. That throws away durable per-user state (api_secret,
livekit_port, rtc_tcp_port once introduced, node_ip) on every
--reset or stale-config-detected path. Operators then have to
re-configure per-user values manually after every restart.

The render_livekit_yaml supervisor regenerates yaml + backend.env
from runtime.json on its next configure / start RPC self-heal, so
keeping runtime.json doesn't break the consistency goal — it just
preserves the durable settings.

This unblocks the "no manual curl bypass" workflow for multi-user
setups: per-user rtc_tcp_port (and other fields) configured once
via configure RPC are durable across restarts.

Companion PR (next): read [livekit] section from hero_cfg.toml and
multi_user_add allocates non-overlapping triples per user.
sameh-farouk force-pushed feat/livekit-per-user-ports-compat from eb0825464f
All checks were successful
Build and Publish Skills / build-and-publish (pull_request) Successful in 4s
Details
to c33f3b7a36
All checks were successful
Build and Publish Skills / build-and-publish (pull_request) Successful in 4s
Details
2026-04-30 01:57:04 +00:00 Compare
sameh-farouk changed title from feat(service_livekit): forward-compat with hero_livekit configure RPC + preserve runtime.json on wipe to feat(service_livekit): forward-compat with hero_livekit configure RPC 2026-04-30 01:58:23 +00:00
sameh-farouk closed this pull request 2026-04-30 02:18:01 +00:00
sameh-farouk commented 2026-04-30 02:18:01 +00:00
Author
Member
Copy link

Superseded by #176, which folds the forward-compat 1-liner from this PR into the same single commit that adds the cfg.toml [livekit] read. Closing as superseded.

Superseded by #176, which folds the forward-compat 1-liner from this PR into the same single commit that adds the cfg.toml [livekit] read. Closing as superseded.
All checks were successful
Build and Publish Skills / build-and-publish (pull_request) Successful in 4s
Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
prio_critical

   
prio_low

   
type_bug

   
type_contact

   
type_issue

   
type_lead

   
type_question

   
type_story

   
type_task
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
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_skills!174
No description provided.