Boyo Execution Barrier
Force ComfyUI to run things in the order you mean — a wire that's also a wall
- input_data
- output_data
ComfyUI executes your graph by dependency, not by position. That's usually great - it finds the fastest valid order automatically. But it's a problem when two branches should happen in a specific order and nothing connects them. If branch A has to finish writing a file before branch B reads it, but there's no data dependency, ComfyUI may run B first, and your workflow produces garbage with no error. Boyo Execution Barrier is the fix: a pass-through node that exists purely to create a dependency edge between otherwise-unconnected branches.
Think of it as a wire that's also a wall. Data goes in input_data and comes out output_data unchanged, but in between, ComfyUI is forced to execute everything upstream of this node before anything downstream. You place it to enforce "X must complete before Y" - sequencing with a cable instead of a promise.
How it works
The node is a pass-through, but it has a barrier_strength dropdown (default medium) that controls how much it isolates, which is where it gets interesting:
light- returns the input untouched. Pure dependency enforcement, zero processing.medium- deep-copies the input (clones tensors). This stops in-place mutation from leaking between branches, which is a real ComfyUI foot-gun: if two branches share a tensor and one mutates it, the other sees corrupted data. The copy severs that.heavy- deep copy plus garbage collection and a CUDA cache clear (empty_cache,synchronize). This is the "I want a clean slate here" option - useful before a big memory-heavy step, at the cost of a performance hit.
So it's not just an ordering tool; it's also a memory-consistency tool. debug_output (default false) prints what the barrier did, which helps when you're convinced a node is reordering things it isn't.
The one input that matters
input_data is wildcard (*), so you can thread any type through it - a latent, an image, an int, anything. The node doesn't care what it's carrying, which is the point: the payload is incidental, the ordering is the feature. Output output_data is the same value back out.
Installation
No dependencies beyond the pack:
cd ComfyUI/custom_nodes && git clone https://github.com/DragonDiffusionbyBoyo/Boyonodes
restart, find it under Boyo/Utils.
When to actually use it
The classic case is a loop or a multi-pass pipeline where branch order matters but the graph doesn't express it. Common examples:
- A save node on one branch must finish before a read/load node on another (the Boyo Image Grab pattern - the file has to exist before it's grabbed).
- An external script or process is triggered mid-graph and downstream nodes assume it completed.
- A shared tensor is being mutated somewhere and you need a copy to protect the other branch.
The honest caveat: heavy runs gc.collect() and clears the CUDA cache every pass, and doing that in a loop is slow. Start with light (ordering only); only escalate to medium if you have a mutation problem, and treat heavy as a last resort. If you need ordering and nothing is mutating, light is the whole job, and it's the cheapest node you'll ever use - the wall that costs nothing but makes the graph behave.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| input_data | * | — | |
| barrier_strengthopt | COMBO | medium | 3 options: light, medium, heavy |
| debug_outputopt | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output_data | * | — |