Nodes/Boyonodes/Boyo Execution Barrier
ComfyUI Node

Boyo Execution Barrier

Force ComfyUI to run things in the order you mean — a wire that's also a wall

By DragonDiffusionbyBoyo·Created 2 years ago·Updated 26 days ago· 16
Boyo Execution Barrier
  • input_data
  • output_data
barrier_strengthmedium
debug_outputfalse

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.

CategoryBoyo/Utils

Inputs (3)

NameTypeDefaultDescription
input_data*
barrier_strengthoptCOMBOmedium3 options: light, medium, heavy
debug_outputoptBOOLEANfalse

Outputs (1)

NameTypeDescription
output_data*