Skip to content

fix(status): broadcast cue names after load on the :9190 channel (869fedahu) - #28

Merged
ibiltari merged 3 commits into
rc_1from
fix/869fedahu-cue-names-broadcast
Oct 8, 2026
Merged

ibiltari merged 3 commits into
rc_1from
fix/869fedahu-cue-names-broadcast

Conversation

@ibiltari

@ibiltari ibiltari commented Oct 8, 2026

Copy link
Copy Markdown
Member

What

The controller now sends one /engine/status/cue_name/<uuid> (string) per cue of the loaded script, replays them to late-joining WebSocket clients, and empties the map on unload. Companion to the UI change in stagesoft/cuems-frontend fix/869fdvdk3-show-loaded-project.

Why

The UI names the engine's next cue from a uuid→name table that only the page on screen filled. GO plays the project the engine holds, so a tab viewing X while the engine held Y showed a raw uuid. The engine already pushes cue/ and cue_enabled/ per cue; the name is the missing member of that family.

Contract (clients)

  • Names are sent after /engine/status/load <project> (unlike cue/ and cue_enabled/, which precede it). Duplicated projects share cue uuids, so a client must treat a change of load as "new table" and refill it from the burst that follows.
  • Late-join dump: after cue_enabled/, before audio/mixer/.
  • Nothing is sent on unload; clients clear on load "".
  • Journal: Cue names initialised for N cues next to the cue-status line.

Scope

ControllerEngine.py only. Node engine, NNG, OSCQuery untouched. Old UIs ignore the address (it falls through their switch); new UI + old engine keeps today's page-fed behaviour.

Verification

  • tests/test_controller_cue_names.py (9, pure unit): walk incl. nested CueLists, burst after load, two loads without unload, late join order, unload, UTF-8 round trip, existing bursts untouched. Full suite 1057 passed on test2 (engine idle).
  • test2 (installed engine rc6-2+nodeadopt1, file patched in site-packages): journal N = N; wire capture with a WebSocket client: counts, order after load, late join, X→Y without unload, unload; UI drills with two/three tabs incl. a duplicated pair with a renamed cue. Restored byte-exact afterwards, dpkg --verify clean.

Notes for the merge

feat/project-status-loaded (cdf8fcf, headed to rc_1) touches the same load_project hunk (it blanks load at the start of a load). Whichever lands second rebases; the burst must stay right after set_status("load", project_name).

Plan + two Opus reviews: cuems-RELATIONS/Plans/2026-10-08-engine-cue-names-broadcast.md. ClickUp 869fedahu.

One /engine/status/cue_name/<uuid> per cue after the load status, replayed
to late joiners, emptied on unload; a second load without unload replaces
the map (duplicated projects share cue uuids). Pure unit tests, safe on a
live rig.
…fedahu)

The UI named the engine's next cue from whatever project its own page had
loaded, so a tab viewing X while the engine held Y showed a raw uuid. The
controller already pushes cue status and enabled flags per cue; the name is
the missing member of that family.

- cue_names built at load from the script (same walk as _collect_cue_ids;
  item.get("name"), None -> "")
- one /engine/status/cue_name/<uuid> per cue, sent AFTER set_status("load"):
  duplicated projects share cue uuids, so clients treat a change of load as
  "new table" and refill it from this burst
- replayed in _on_ws_client_connect after cue_enabled, before mixer
- emptied on unload; nothing is sent then (clients clear on load "")
- "Cue names initialised for N cues" next to the cue status line

Node engine untouched. Verified on test2 (rc6-2+nodeadopt1 base): wire
capture order, late join, X->Y without unload, unload; full suite 1057 passed.
@ibiltari
ibiltari merged commit b6d8570 into rc_1 Oct 8, 2026
2 checks passed
@ibiltari
ibiltari deleted the fix/869fedahu-cue-names-broadcast branch October 9, 2026 09:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant