Zura · Read Stage Signal

The other half of the stage hand-off. Something packed up to 64 named values into a ZURA_STUDIO_SIGNALS bundle; this node pulls exactly one of them back out by name.

It's a two-input node, which tells you everything about its scope: stage_data (the bundle) and key (the name you want, as a plain string, default empty). Out comes * - the wildcard type, because the node genuinely doesn't know whether it's handing you an image, a width or a cache key. It just knows the name matched.

Why a node this small exists

Because graphs get read by humans. When Zura Studio exports a stage to Graph view, the stage's upstream values have to arrive at the sampling graph somehow, and one bundle wire plus a couple of readers is far easier to audit than eight loose connections crossing a group boundary. The alternative - re-loading the footage, re-detecting the character, re-deriving the resolution in stage three - would be slow and, worse, could silently disagree with what stage one actually approved.

It also matches how the ecosystem generally solved this. A typed primitive fanned out to three consumers is the standard fix for "the same value in four widgets"; a context bus is the standard fix for "forty wires crossing everything." This is the second pattern, implemented narrowly.

How it actually behaves

At run time it does a dictionary lookup and checks membership. If the key isn't there, you get "The previous stage has no signal named <key>" - a hard error, at queue time, naming the thing. It will not return None and let you find out four nodes downstream that your mask was empty. Given the alternative, that's the right trade.

The output type being * has a real consequence worth flagging: ComfyUI's type checker has nothing to check. Plug this into an IMAGE socket and it connects. Plug it into a MASK socket and it connects. If the key holds the wrong kind of object, you find out when the consumer tries to use it - often with a confusing message from the consumer rather than from here. When a graph that was working suddenly isn't, check the key names before you check anything expensive.

The pack's own graphs use this pattern heavily: stage signals carry footage, approved masks, resolution integers, cache keys and provenance strings across the stage boundary, and the guard nodes downstream re-verify the ones that matter rather than trusting the pipe.

Install

Part of the pack:

cd ComfyUI/custom_nodes && git clone https://github.com/ZURAVFX/ComfyUI_zura_nodes
pip install -r ComfyUI_zura_nodes/requirements.txt

Or install Zura Nodes through ComfyUI Manager (publisher ZURAVFX) and restart ComfyUI. No models, no dependencies beyond the pack itself - it never touches tensors.

Common issues

"The previous stage has no signal named …" - the reader's key doesn't match any entry in the packer's keys list. This is almost always a typo, a case difference, or a stale reader left over from an older version of the exported graph. Re-export the stage and start from the fresh graph rather than hand-fixing key names; the pack regenerates the whole bundle together.

It connects to the wrong socket and produces nonsense. Yes, that's the wildcard. There's no type safety to catch you, so name your keys after what they are (source_frames, approved_mask, render_width) rather than what stage produced them, and keep the reader adjacent to its consumer so a wrong pull is visible.

"The previous stage has no signal named " with an empty key. The key widget defaults to an empty string. If you drop this node fresh and queue, that's what you asked for. Fill it in.

Chain of bundles loses a key. Nothing here is a deep merge you can reason about loosely. If a later stage re-packs with previous connected, same-named values get overridden in place. If two stages use the same key name for different things - one meaning a frame count in 720p terms and one in 1080p - you'll get the second stage's value with no warning.