flow_whileEnd
The condition check that actually closes the loop
- flow
- initial_value_0
- initial_value_1
- initial_value_2
- initial_value_3
- initial_value_4
- initial_value_5
- initial_value_6
- initial_value_7
- initial_value_8
- initial_value_9
- initial_value_10
- initial_value_11
- initial_value_12
- initial_value_13
- initial_value_14
- initial_value_15
- initial_value_16
- initial_value_17
- initial_value_18
- initial_value_19
- value_0
- value_1
- value_2
- value_3
- value_4
- value_5
- value_6
- value_7
- value_8
- value_9
- value_10
- value_11
- value_12
- value_13
- value_14
- value_15
- value_16
- value_17
- value_18
- value_19
If you've read the flow_whileStart article you know the shape of this pair: Start opens the loop, End closes it. What's easy to miss is that the two condition inputs aren't the same question. Start's condition defaults to true and just gates whether the loop runs at all this execution. End's condition has no default - you have to wire something real into it, because it's re-checked after every single lap and it's the one that actually decides whether you go around again.
How it works
flow_whileEnd takes the flow token from flow_whileStart (or from further down the loop body) and a fresh condition each pass. If condition is true, it feeds its initial_value_0…19 inputs - whatever your loop body just produced this lap - back around as the next lap's starting values, the same way flow_whileStart does on lap one. If condition is false, the loop stops and those same values come out as this node's final value_0…19 outputs instead. There's no flow output here, because there's nowhere left for it to go - this is the exit.
The mechanism is the same re-execution trick described in the flow_whileStart article: ComfyUI has no native back-edges, so the pair fakes a loop by re-running the graph segment between Start and End with updated inputs, rather than looping in the traditional sense.
The inputs and outputs that matter
flow(required) - must come from a matchingflow_whileStart, or from a chain that traces back to one.condition(required, no default) - this is the one you actually have to build. A raw counter comparison, a threshold check on an image metric, whatever your stop condition is - it needs to change as the loop runs, or you'll either never enter a second lap or never leave.initial_value_0…19(optional, typed*) - plug in each loop-body output here, numbered to match the slots you used onflow_whileStart.- Output:
value_0…19- the final values onceconditiongoes false, ready to feed into the rest of your graph.
How to install it
Same pack, same steps as flow_whileStart: via ComfyUI Manager, search ComfyUI-Apt_Preset and install; or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/cardenluo/ComfyUI-Apt_Preset.git
then Windows users double-click install.bat, Linux/Mac users pip install -r ComfyUI-Apt_Preset/requirements.txt inside their venv, and restart ComfyUI. No model downloads for flow control - the heavier dependencies in requirements.txt (pandas, gguf, onnxruntime, audio/video libraries) are there for other corners of this fairly large, actively maintained pack (roughly 300 GitHub stars, MIT-licensed), not for this node.
Common issues & troubleshooting
An unwired condition will error, not silently default to true. Unlike Start, End doesn't assume you want to keep going - if you forget to wire a real stop check here, expect the queue to complain rather than loop forever by accident. That's a feature: it forces you to actually decide the exit condition instead of inheriting Start's "always run" default.
Mismatched slot numbering breaks the loop quietly. The same rule as flow_whileStart applies here: value_5 and initial_value_5 on the two nodes are one continuous variable across laps. If you renumber halfway through wiring, the loop keeps running - it just carries the wrong data.
No built-in cap on iterations. Nothing in the schema stops a condition that never resolves false. If a run hangs, that's very likely a flow_whileStart/flow_whileEnd pair with no real exit logic - wire a counter through one of the value slots and check it explicitly if you're not fully confident the natural condition will trip.
This solves bounded, in-graph repetition - not batch variation. For "run this block twenty times with different prompts," the ComfyUI API plus a small script is what most people reach for instead; loop pairs like this one are the right tool when you're repeating the same operation on evolving state a handful of times (upscale until sharp, correct until a threshold), not for mass-producing unrelated outputs.
Inputs (22)
| Name | Type | Default | Description |
|---|---|---|---|
| flow | FLOW_CL | — | |
| condition | BOOLEAN | — | |
| initial_value_0opt | * | — | |
| initial_value_1opt | * | — | |
| initial_value_2opt | * | — | |
| initial_value_3opt | * | — | |
| initial_value_4opt | * | — | |
| initial_value_5opt | * | — | |
| initial_value_6opt | * | — | |
| initial_value_7opt | * | — | |
| initial_value_8opt | * | — | |
| initial_value_9opt | * | — | |
| initial_value_10opt | * | — | |
| initial_value_11opt | * | — | |
| initial_value_12opt | * | — | |
| initial_value_13opt | * | — | |
| initial_value_14opt | * | — | |
| initial_value_15opt | * | — | |
| initial_value_16opt | * | — | |
| initial_value_17opt | * | — | |
| initial_value_18opt | * | — | |
| initial_value_19opt | * | — |
Outputs (20)
| Name | Type | Description |
|---|---|---|
| value_0 | * | — |
| value_1 | * | — |
| value_2 | * | — |
| value_3 | * | — |
| value_4 | * | — |
| value_5 | * | — |
| value_6 | * | — |
| value_7 | * | — |
| value_8 | * | — |
| value_9 | * | — |
| value_10 | * | — |
| value_11 | * | — |
| value_12 | * | — |
| value_13 | * | — |
| value_14 | * | — |
| value_15 | * | — |
| value_16 | * | — |
| value_17 | * | — |
| value_18 | * | — |
| value_19 | * | — |