File Paths For Loop Sync Resume

"File Paths For Loop Sync Resume" is the quiet half of the ComfyUI-FilePathsFromFolder pack's batch-sync pair. Its partner, File Paths For Loop Sync Trigger, is the one that starts a one-time operation mid-batch; this node is the one that waits for it to finish before letting the batch continue. The author's own docstring nails its personality in four words: "Just a wait point." It doesn't transform data, it doesn't count anything, it doesn't even look at what you feed it - it's a barrier with a hole in it.

Here's the situation it solves. Your workflow runs in batched stages (remember, File Paths For Loop Start uses list batching, so ComfyUI tends to run "load all → process all → save all"). Between stages you want something done exactly once - clear VRAM, swap models, save a checkpoint. The Trigger splits your batch into a trigger single value for that one-shot operation and an anything passthrough for the rest of the batch. This Resume node is where the two paths rejoin, and it refuses to let the batch through until your one-shot reports back.

The inputs

• anything - any-type, forceInput. Connect this from Sync Trigger.anything. This is the batched data, kept as a batch (OUTPUT_IS_LIST on the output means downstream continues per-item).
• wait_for - any-type. Connect this from your one-time operation's output. It's the completion signal. The node doesn't inspect it - it just needs to be connected, so that the graph knows the one-shot runs before the batch moves on.

Both are required, which is the honest part of the design: the node can't do its job unless both halves of the barrier are wired.

The output

• anything - the same batch it received, passed through unchanged. Continue your workflow from here and the batch proceeds past the sync point.

How it works under the hood

The function body is literally return (anything,). All the work happens in the wiring and the execution graph: because wait_for must be satisfied before anything can flow out, ComfyUI's execution order forces the one-time node to complete first. It's the graph-structure guarantee, not the Python, that makes the wait real. That's a nice little example of how much of ComfyUI's "logic" is just carefully arranged dependencies.

When to reach for it

Only when you have a genuine "once between two batched stages" need - the README's example (LLM batch → clear VRAM once → text-to-image batch) is the classic one. Small folders and short runs don't need the ceremony; add a barrier only when a batch stage is big enough that a cleanup or a model switch matters. And remember: a Resume without its Trigger is pointless, because nothing created the single trigger value in the first place. They ship as a pair and only make sense as a pair.

Same install as the rest of the pack - one clone, no dependencies:

cd path/to/ComfyUI/custom_nodes
git clone https://github.com/RockyHong/ComfyUI-FilePathsFromFolder.git

Restart, then look for "File Paths For Loop Sync Resume" in the node menu. If you find yourself wondering "why won't my batch finish," check that both anything and wait_for are actually connected - an unwired wait_for is the most common way this node leaves you stuck at the barrier.