Loop Over Items (core.loop)

Process items in batches: the loop hands out batch_size items at a time to the body you wire to its loop output, and releases everything to done once the last batch returns. Use it for rate-limited APIs, chunked writes, or any step that must not see all items at once.

Parameters

Wiring

Two outputs, one convention:

• done (top) — fires once, after every batch has been processed; carries all items onward.
• loop (bottom) — the current batch. Wire your processing nodes here, and wire the last body node back into the loop's input to close the cycle. The canvas draws this loop-back edge as a downward bow.

trigger → loop ──done──→ after
            └──loop──→ body ──→ (back into loop)

Behavior

Batches are handed out in input order — batch 0 is items 0…N-1, and so on. The final batch may be smaller. Items keep their binary attachments and lineage through the cycle.

The body can drop items. A filter or IF inside the body that diverts an entire batch off the loop-back edge doesn't stall the run — the loop refires and continues with the remaining batches.

A body error follows the normal error rules (on_error on the failing node): with the default stop, the run fails mid-loop; already-processed batches keep their recorded output.

Loops can nest and chain — a loop's done output can feed another loop.

Step batches from the editor

The loop's detail view has a stepper — ▶ batch 0 runs just the first batch, next batch ▶ advances one batch per click, painting each batch's output in place without re-running the workflow. Stepping past the end emits an empty batch. Combined with the ▶ execute node control on downstream nodes (which runs them on the latest recorded data — the stepped batch), you can debug a pipeline batch by batch. A normal run is unaffected: "run to the end" always processes every batch.

Quirks & tips

• Forgetting the loop-back edge is the classic mistake: without it, the first batch reaches your body and the loop never advances. If your run processes exactly batch_size items and stops, check the wiring.
• The loop's position/cursor lives in the run, not the definition — every new run starts from batch 0.
• done carries the body's processed items — what came back around the loop-back edge (transformations included), accumulated across all batches in order. Items the body dropped mid-loop are absent from done.

Related

• Split Out — explode a list into the item stream the loop batches.
• Filter — inside the body, to drop items mid-loop.
• Execute Workflow — call a sub-workflow per batch for heavy bodies.