Execution Order Controller

Execution Order Controller is a plumbing node that solves a very specific, very annoying problem: ComfyUI decides its own execution order, and sometimes it's the wrong one. This node lets you pin it. You wire the output of the node that must run first into the signal input, pass the data for the node that must run later through value, and now the second thing can't start until the first has finished.

You don't need this often, but when you need it there's no clean substitute. ComfyUI walks the graph in whatever order satisfies the dependencies, and for most workflows that's fine - the wires already encode what depends on what. The trouble comes when two branches have no data dependency between them but you still care about sequence: freeing VRAM before a heavy node loads, making sure a save completes before something overwrites it, or running one sampler before another when they'd otherwise race. There's no wire that expresses "just do this one first," so this node manufactures one.

How it works

The node has two wildcard-typed passthroughs, signal and value, and both accept anything. The trick is dependency injection: because value only becomes available after the node runs, and the node can't run until signal is satisfied, anything downstream of value is now forced to wait for whatever you plugged into signal. You're not transforming data - value comes out unchanged - you're borrowing ComfyUI's own dependency resolution to impose an order it wouldn't have picked. Connect the "run me first" node's output to signal, route the "run me later" node's input through value, and the sequence is guaranteed.

This is part of a small family of ordering and control nodes in the pack that lean on ComfyUI's execution model (the pack gained a lot of this after ComfyUI added execution-order inversion support), alongside things like Switch (Any) and the queue-trigger loop nodes.

The inputs and outputs that matter

There are only two of each, and they mirror:

• signal (required, any type) - connect the output of the node that should run first. Its value is ignored; its completion is the point.
• value (required, any type) - the data you want to hold back. Route the later node's input through here.

Outputs:

• signal - passes the signal through, so you can daisy-chain ordering constraints.
• value - your data, unchanged, now gated behind the signal.

That's the whole node. It does nothing to the data; it only rearranges when things happen.

How to install it

Install the pack via ComfyUI Manager (search ComfyUI Impact Pack, install, restart), or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack comfyui-impact-pack
cd comfyui-impact-pack
python -m pip install -r requirements.txt   # ComfyUI's python; python_embeded on portable

then restart. No models, no dependencies beyond the pack itself. This is pure graph-control glue.

Common issues & troubleshooting

It didn't change the order. Make sure the data path actually goes through value. If the later node still gets its input from somewhere else in parallel, the node has nothing to gate - the constraint only holds for whatever flows through value. Similarly, signal has to come from the node you want to finish first; a stray constant wired in imposes no real wait.

Type errors on the wildcard inputs. Many Impact Pack nodes use a wildcard type for arbitrary connections, and ComfyUI's validator sometimes complains even when it works. The pack's own docs note this - it functions, but type validation may still print messages. If the graph runs, you're fine.

Do I actually need this? Usually not. Reach for it only when you have a genuine ordering requirement with no data dependency to express it - VRAM sequencing, save-before-overwrite, deliberate serialization. If a normal wire already encodes the dependency, let ComfyUI handle it and skip this node.