InnerLoopClose

What it is

InnerLoopClose is the closing bracket of this pack's for-each loop construct - the counterpart to ForEachOpen (a separate node in the pack, not covered in this batch). ComfyUI doesn't have a native loop primitive; a community observation about the graph model puts it bluntly: after years of the project existing, loops and conditionals are still fundamentally a hack layered on top of a graph engine that wasn't designed for them. This pack's answer to that gap is a matched pair of nodes - one that opens an iteration and one, this one, that closes it, carrying values between passes so a loop can actually accumulate state instead of starting fresh every time.

The mental model: ForEachOpen starts an iteration over something (a list, a batch), you do whatever work you want inside that iteration, and then InnerLoopClose gathers up whatever values need to survive into the next iteration - a counter, a running total, an accumulated list - checks whether the loop should continue via condition, and either loops back with the updated values or lets execution fall through to whatever comes after the loop.

Inputs and outputs

• flow_control (FLOW_CONTROL, required) - the loop-control signal coming from the matching ForEachOpen.
• condition (BOOLEAN, required) - whether the loop should continue. Typically the output of an InnerIntCompare check (has the counter reached the list length yet, and so on).
• initial_value0 through initial_value19 (all type *, optional) - up to twenty slots for whatever values need to be carried from this iteration into the next. Wire in a counter, an accumulator, whatever state your loop body needs to remember.

Outputs mirror the inputs one for one: value0 through value19 (all type *) - the carried-forward values, handed back to be used both inside the current graph and as the seed for the next iteration.

How it works

Twenty generic numbered slots rather than named parameters is a deliberate, if slightly blunt, design choice - it means the node doesn't need to know in advance what kind of state your particular loop is carrying (a counter, an image list, a running JSON object, all at once if needed), at the cost of you having to keep track of which slot is which by position rather than by name. Slot 0 in is slot 0 out, and so on; there's no reordering or relabeling happening inside the node.

Installing it

Part of comfyui-easyapi-nodes. Through ComfyUI Manager: search "comfyui-easyapi-nodes", install, restart ComfyUI. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/lldacing/comfyui-easyapi-nodes.git
cd comfyui-easyapi-nodes
pip install -r requirements.txt

You'll want ForEachOpen from the same pack installed alongside it - this node has no purpose on its own without its opening counterpart. git pull in the folder to upgrade later.

Common issues

"My loop runs forever, or doesn't run at all." Check condition first. If it's wired to something that never changes between iterations (the classic bug: feeding in the counter's initial value on every pass instead of the value carried forward from the previous iteration), the loop will either never stop or never start, depending on which way the logic points.

"My accumulated value keeps resetting instead of building up." Make sure the state you want to persist is actually going through an initial_value slot on this node, not just computed fresh inside the loop body and discarded. Only values that pass through InnerLoopClose's numbered slots survive into the next pass.

"I lost track of which slot number is which." With twenty generic slots and no labels, this is the main real friction of the design - the practical fix is discipline rather than a node feature: keep a consistent slot ordering across your loop (slot 0 is always the counter, slot 1 is always the accumulator, or whatever convention you pick) and note it somewhere, because the graph itself won't remind you.

"How do I get out of the loop once condition is false?" That's handled by the loop-close mechanism itself once condition flips - the node's flow_control output routes execution to fall through to whatever's wired after the loop rather than back to ForEachOpen. If nothing seems to happen after the loop ends, check that something is actually connected past this node for execution to fall into (this pack's EmptyOutputNode is the standard cap if you have nothing else to output there).