Stage Path (Internal)

So there's a node in your saved workflow you never placed: TuringUtilsStagePath, rendered as "Stage Path (Internal)", sitting in a category literally called internal. If you haven't used this pack's Stage Barrier node, you've likely never seen it and never will. If you have, this explains the ghost.

The story starts with Stage Barrier, the user-facing node in this pack. It lets you tag independent value paths with a stage label - say 0 for VAE/reference prep, 1 for sampling, 2 for decode - and the pack installs a scheduler that executes those paths in dependency rounds without faking data dependencies between unrelated branches. That's genuinely useful for big graphs where lazy branches and shared values make execution order surprising.

But there's a ComfyUI engine fact in the way: the engine caches and schedules whole nodes, not individual output sockets. A multi-input pass-through hub like Stage Barrier therefore makes every connected input a hard dependency of the hub - which quietly defeats the lazy nodes you built to skip the unselected branch. The pack's fix is elegant: when you submit a workflow, a server-side prompt compiler (compile_stage_barrier_prompt, hooked in via ComfyUI's add_on_prompt_handler) rewrites each Stage Barrier port that's actually used into a private, one-input/one-output route node. That route is TuringUtilsStagePath. Each one carries a node id shaped like <barrier>.turing_stage_path.<index>, copies the barrier's stage label, and forwards exactly one value. Now each port compiles into its own cache and execution path, so unselected lazy branches genuinely stay skipped.

That's why the node description says "the server creates this node while compiling a submitted workflow" - it's generated, not hand-drawn. It's marked is_dev_only, which is ComfyUI's way of hiding it from the normal node menu. It is not something you should be adding from a search box, and in a normal session you can't.

What it looks like

One socketless stage widget (an integer, default 0, copied from the barrier it was compiled from), one optional value input of any type, one value output of any type. It is a pass-through: in one end, out the other, stage label intact. Negative stages raise an error, so keep them at zero or above. That's the entire surface.

When you'll trip over it

• You opened a workflow you didn't build and the loader complains about a missing node named TuringUtilsStagePath. That means the graph was authored with this pack installed and the routes are baked into the JSON. Install the pack (cd ComfyUI/custom_nodes && git clone https://github.com/wjie98/comfyui-svdint4 then restart) and the ghost becomes a loadable node again.
• You saved a Stage Barrier workflow mid-flight and later spot these entries in the raw JSON. Not corruption - that's the compiled form. Save and reload through the same pack and it round-trips fine.
• Nothing appears to reorder. The barrier scheduler wraps ComfyUI's ready-node picker, and on a ComfyUI build that lacks the expected scheduling surface it logs a warning and declines to activate rather than crashing. If your Stage Barrier workflows run but never actually reorder, check your ComfyUI version and the log line about the scheduler being unavailable.

One honest note: none of this is GPU or CUDA work. Stage Barrier and Stage Path are pure-Python scheduling machinery - no kernel build, no model files - even though the pack they live in is best known for compiled quantization kernels. If you only care about execution ordering, you can ignore the README's compile step entirely.