GetJobStep

Not everything needs to run the full loop. Sometimes you're still building the workflow and just want to check "what does step 7 actually contain" without queuing every step to find out. Other times you want most of the graph to iterate normally but one part - a reference image, a fixed control seed - pinned to a single specific step no matter what. GetJobStep does that: reach into a job by index and pull out just that one step's attributes.

How it works

It's a direct index into the job (which, under the hood, is just a Python list of attribute dictionaries), with two different behaviors for what happens if the index you ask for is out of range. repeat wraps around with modulo - ask for step 15 of a 10-step job and you'll get step 5, and negative indices wrap the same way. clamp instead pins the index to the nearest valid bound, so asking for step 15 on a 10-step job just gives you the last step instead of wrapping around to somewhere in the middle.

It's worth being clear about what this node doesn't do: it pulls a single step, not the whole list, and it does not itself trigger ComfyUI's per-item loop execution the way JobToList does. If you want the full sweep to actually run, JobToList is the node for that - GetJobStep is for grabbing one fixed slice out of it.

The inputs and outputs that matter

• job (JOB) - the job to index into.
• step (INT) - which step to grab.
• wrap - repeat (modulo wraparound) or clamp (pin to the valid range).

Output is a single attributes (ATTRIBUTES) - feed it into GetAttribute or one of the typed variants to pull individual values back out.

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

Testing a workflow before committing to the full run. Point step at 0, wire the output through your usual GetAttribute chain, and run the graph once normally (not through JobToList) to sanity-check the wiring before you trust it to loop over hundreds of steps unattended.

step set higher than expected and you're not sure why the result looks the same. If wrap is set to repeat and your job is shorter than you thought, indices wrap around - step 12 on an 8-step job quietly becomes step 4. Check count from whatever built the job (CombineJobs or EnumerateJob) if the wraparound is catching you off guard.

Pinning one part of the graph while the rest iterates. This is a legitimate pattern: wire JobToList's list output into the part of the graph that should sweep, and a separate GetJobStep(job, step=0) into a part that should stay fixed - like always encoding step 0's prompt as a reference caption regardless of which step is currently rendering.