Concurrent Collect Images (30)

This is the node that makes every Concurrent Submit node in the pack make sense. ComflyConcurrent_Image_Await - displayed as Concurrent Collect Images (30) - is the receiving end of the pattern: the Submit nodes fire cloud jobs into a 30-worker pool and hand you task futures; this node waits for all of them and hands back real images. No Await node, no images. It's the collector, and it's an output node - you queue the batch, it holds the line until the pool drains, then you save.

It's also the place where the whole concurrency story becomes visible, because the pool size is right in the name: 30 image workers. Queue 30 Submit nodes, they run in parallel, and this node restores them to the order you connected them. The pack's README (2026085-1) says it plainly: search "Concurrent" in the node menu and you get the whole family - this collector plus a Submit variant for every eligible image/video node.

How it works

You connect task_1 through task_30 (only task_1 is required; unconnected slots report not_connected). Each is a COMFLY_IMAGE_FUTURE from any image Submit node in the pack - they can be a mix of different models, since the pool is shared. On execution the node waits on all pending futures with a ComfyUI progress bar, then hands back:

• image_1 … image_30 - IMAGE tensors in the exact slot order of their tasks.
• status - a JSON string describing every slot: not_connected, pending, success, or failed (with the error message, sanitized so it doesn't leak your key or URLs).

The failure_mode input decides what happens when a slot fails:

• fail_fast (default) - the first failure cancels the remaining queued tasks and raises. You learn about the problem immediately, but you eat the already-submitted work.
• placeholder - failures are replaced with a placeholder (a small flat-color image) and the run completes. You get all 30 slots filled and read the status JSON to find the dead ones. Better for "don't waste my batch" workflows.

IS_CHANGED returns NaN, which is ComfyUI-speak for "this node always re-runs" - the collector re-polls its tasks every queue, exactly what you want for a wait node.

Inputs and outputs, briefly

• task_1 (required) and task_2–task_30 (optional) - COMFLY_IMAGE_FUTURE inputs from the Submit nodes.
• failure_mode - fail_fast / placeholder.
• image_1…image_30 - IMAGE outputs, slot-ordered.
• status - STRING summary JSON.

Install

It ships with the pack - no separate install:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-zhenzhen

or ComfyUI Manager → search "Comfyui-zhenzhen" → install → restart.

Where people get burned

• Task futures are not images. The most common mistake in the entire family: wiring a Submit node's task straight into a Save Image node. It has to pass through the collector first.
• fail_fast can nuke a good batch. One flaky slot and the whole queue cancels. If you're batch-heavy, placeholder is usually the better default - you still get your good images, and status tells you which to re-run.
• The collector re-runs every queue. Because it's a wait node with NaN IS_CHANGED, it re-polls even if nothing changed upstream. That's correct behavior, but it means an unmodified queue is not a free cache hit.
• Sanitized errors. Failure messages redact API keys and URLs (deliberately - the source does this so a shared workflow doesn't leak your credentials in the error text). That's good for security and mildly annoying for debugging; the site's async-task list is the place to dig deeper.

One more security note that's worth its own sentence: this pack is arbitrary Python that carries API keys and phones home by design, and the collector is where a whole batch's worth of prompts and reference images converge. Keep your key out of shared workflow JSONs, and prefer installing from the official repo via Manager.