Simple While Close
Where the loop actually decides whether to keep going
- flow
- initial_value0
- initial_value1
- initial_value2
- initial_value3
- initial_value4
- value0
- value1
- value2
- value3
- value4
This is the business end of huyl3-cpu's while-loop pair. SimpleWhileOpen just sets up the loop and hands you a FLOW_CONTROL wire; SimpleWhileClose is where the actual decision happens each pass - keep looping, or let the results out.
You wire your loop body's output back into this node: the flow signal from the chain of nodes between Open and Close, a freshly re-evaluated condition, and the updated working values. While condition stays true, SimpleWhileClose feeds those updated values back to the top of the loop for another pass. The moment it flips false, the node stops looping and pushes the final values on downstream - the loop is over, and the rest of your graph continues normally.
The inputs and outputs that matter
- flow - the
FLOW_CONTROLinput, wired from the end of your loop body (which traces back toSimpleWhileOpen'sflowoutput). - condition - a BOOLEAN, re-evaluated fresh each pass through the loop. This is the actual stop check - as long as it's true, the loop repeats; once it's false, this node releases its outputs and the loop ends.
- initial_value0 through initial_value4 - five optional slots (
*), one worth flagging clearly: despite the field name matchingSimpleWhileOpen's, here they represent the updated values coming out of this pass of the loop, not the loop's original starting values. It's a mildly misleading name inherited from the Open node's field, not a separate "initial" concept.
Output: value0 through value4 - the final values, released once condition goes false. Notice there's no flow output here, because there's nothing left to route into - this is the end of the loop, not another link in the chain.
Installing it
ComfyUI Manager: search comfyui-huyl2-nodes. By hand:
cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist
restart. As with SimpleWhileOpen, the pack's README doesn't cover this node at all - it documents one unrelated node and nothing about the flow-control pair. Treat the schema and a small test graph as your actual documentation here.
Common issues & troubleshooting
The single most common failure mode with any loop like this: condition never goes false, and your workflow just hangs. There's no built-in max-iteration safety net in this pair - that's on you to build into whatever logic computes condition each pass. If a run seems to freeze rather than error, this is the first thing to check.
Second: since initial_value0–initial_value4 here are really "current value going into the next pass," not literal initial values, double-check you're feeding this node the updated result of your loop body's work each time, not accidentally re-wiring the original seed values from SimpleWhileOpen. Re-feeding the unchanged originals will make your condition check the same thing every pass - which, depending on your logic, either loops forever or exits on the first check, neither of which is usually what you meant.
And as with the Open node, keep your numbered slots consistent between the two ends - nothing enforces that value2 on Close corresponds to whatever you called initial_value2 on Open; a mismatch fails silently rather than loudly.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| flow | FLOW_CONTROL | — | |
| condition | BOOLEAN | — | |
| initial_value0opt | * | — | |
| initial_value1opt | * | — | |
| initial_value2opt | * | — | |
| initial_value3opt | * | — | |
| initial_value4opt | * | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| value0 | * | — |
| value1 | * | — |
| value2 | * | — |
| value3 | * | — |
| value4 | * | — |