Zura · Check Motion Section

Every number this node checks is a way a long render can go wrong silently, and the error it raises is the best line in the pack: "Update section before queuing."

Studio exports a bounded Wan stage to Graph view as a section-by-section graph. You then queue it once per section - the graph doesn't loop itself, you press Run, section 1 happens, you advance, section 2 happens. Which means the graph can be stale: the plan it's carrying was written for a shot, an opening appearance, an audio in-point and a mask approval that may no longer be the current ones. This node is a queue-time consistency barrier that refuses to let a stale graph render twenty minutes of footage against the wrong pins.

Inputs and outputs

One visible input: plan_json, a multiline string, default empty. It's the section's plan document, and it's big - the node caps it at 2 MB and rejects anything over that as "The section plan is missing or exceeds its metadata limit."

It also declares two hidden inputs, which is why you can't just drop it in a random graph and expect it to work: the expanded API prompt and the node's own unique id. The first lets it find itself in the prompt it was handed, and the second lets it verify that it is the same node whose plan_json is in the prompt. Move the guard, edit its plan, and the identity check fails.

Four outputs:

• motion_key - a STRING, the section's motion identity
• section_start - INT
• section_length - INT
• guide_start_time - FLOAT, the in-point on the speech guide, which downstream nodes use to align audio

What it actually checks

The docstring is explicit that it "reads only its small plan JSON, the expanded API prompt, reviewed metadata and preparation receipts. It never opens tensor caches or media and does not approve source assets." So it's cheap and it runs before anything expensive.

In practice it verifies, in order: the plan's schema and field set are current; the motion key is a valid digest and still hashes from its own key payload (a changed payload means the provenance moved); the project pins are complete and well-formed, including the approval, character, opening and audio hashes; the section is the next canonical range - start_frame divisible by the section bound, length exactly min(bound, total - start), where the bound is 41 for 1920-wide renders and 81 otherwise; the source, review, mask and facial-guide pins still match; and finally it reads the saved Studio project record and compares its pins to the plan's, ignoring only resolution and scope because Graph view deliberately owns those two.

Then it checks the live prompt: the node at its own unique id must still be this class with this exact plan_json. So if you duplicated the guard, or hand-edited the plan to skip a section, that's caught with the same blunt message.

If the recorded audio or lip sync flags changed, or the source interval moved, you get "The saved source, appearance, interval or speech settings changed" - and the only correct response is to go back to Studio, re-approve, and re-export the stage.

Install

It ships with the pack:

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

Manager: Zura Nodes (publisher ZURAVFX), restart. Nothing extra for this node - no models, no ffmpeg, no detection weights. It's metadata validation and it's pure Python.

Common issues

"Update section before queuing. …" Whatever follows the period is the actual reason, and it's worth reading rather than reflexively re-exporting. If it says the section isn't the next canonical range, you pressed Run twice on the same section or skipped one. If it says the saved mask approval changed, you re-reviewed the shot and the graph predates that.

"The section guard was moved or its plan changed." You edited plan_json by hand, or you copied the node into a graph where it isn't the same node id the prompt was prepared for. Don't hand-edit the plan; the plan is generated.

It always re-runs on every queue. Deliberate - an always-changed check, because the cursor has to be re-validated against fresh receipts each press of Run. It costs almost nothing, and it's the difference between a wrong render and an error message.

An older saved graph fails to queue. Saved Graph-view plans from before the viewport flag existed are treated as motion-transfer, so that particular case is handled. But a plan from before a schema change simply won't validate, and the honest fix is to re-export the stage from Studio rather than trying to repair the JSON.