JobToList

ComfyUI has no native for-loop. There's no button for "run this graph once per item in a list" - people ask for exactly that on r/comfyui under names like "prompt matrix" and get pointed at this pack in reply. comfyui-job-iterator's own tagline is blunt about it: it bills itself as "a for loop for ComfyUI." JobToList is the node where that promise actually gets delivered - everything downstream of it runs once per step in your job.

It's also the node the pack's README specifically tells you to swap in if you're fixing up an older workflow: an earlier node called JobIterator used to do this job and has been removed, replaced by JobToList.

How it works - and it's not what it looks like

Here's the honest version, straight from the source: the node itself does almost nothing. Its entire implementation is return (job,). The looping isn't computed by this pack at all - what makes it work is that the output is declared OUTPUT_IS_LIST = True, which taps directly into ComfyUI's own native list-execution engine. Any node chain wired to a list output gets fanned out by ComfyUI's own scheduler and cache, effectively re-run once per item, using ComfyUI's execution model rather than a Python loop this pack wrote itself. JobToList is really just the adapter handing your JOB (a plain list of attribute dictionaries) to machinery ComfyUI already has.

That distinction isn't academic. Because the "loop" leans on ComfyUI's list execution rather than acting like a literal procedural for-loop, it doesn't necessarily finish one full pass - sample, decode, save - before starting the next. Some users have reported that after a ComfyUI core update, a big sweep started executing node-by-node across every step of the job before moving to the next node type in the chain, rather than completing one image at a time. That's harder to debug mid-run, and it can mean more models staying loaded in memory at once than a strictly sequential, one-step-at-a-time execution would. It's worth testing a short 2-3 step job first and watching how your particular ComfyUI build actually schedules it before trusting an overnight sweep to behave the way you'd expect from a real for-loop.

The inputs and outputs that matter

• job (JOB) - built upstream with MakeJob and, optionally, combined with CombineJobs or EnumerateJob.

Output is attributes (ATTRIBUTES, is_list: true) - wire it straight into GetAttribute, GetAttributeInt, GetAttributeFloat, or GetAttributeString nodes, one per value you need pulled out at each step, and from there into your normal sampling/encoding graph.

How to install it

Via ComfyUI Manager: search comfyui-job-iterator, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ali1234/comfyui-job-iterator

then restart. No dependencies.

Common issues & troubleshooting

You've got an old workflow using a "JobIterator" node and it's missing. That node was removed; replace it with JobToList per the README's own migration note.

A big sweep behaves strangely mid-run, or seems to load more models than expected. See the mechanism section above - this is a known characteristic of leaning on ComfyUI's list execution rather than a true sequential loop. Test small before you test big.

Nothing downstream seems to iterate at all. Make sure you're actually consuming the attributes output as a list - a GetAttribute node wired directly to it is the normal path. If a node in between declares INPUT_IS_LIST in an unexpected way, it can absorb the whole list at once instead of letting it fan out per item.