flow_stage_collect_multi

If flow_stage_collect_single is the finish line for pipelines where every stage feeds one shared port, flow_stage_collect_multi is the version for pipelines where each stage ends at its own node with its own output socket. Instead of one video port reused across stages, you get dynamic value_1, value_2, … inputs - one per stage - and you wire each stage's output into its numbered port. The node holds onto them and, on the final stage, assembles them into the same five outputs: image_batch, mask_batch, latent_batch, merged_video, merged_audio.

How it works

The mechanics mirror the single variant - per-stage saves to a run directory, execution blockers until the last stage, then load-and-merge - but there are two differences worth knowing before you pick between them.

First, the node locks the type on stage one. Whatever you feed value_1 becomes the contract: it writes the detected kind (image, mask, latent, video, or audio) to a type.json, and every later stage must match it or you get a TypeError ("value_2 must be image, got mask"). That's a feature - it stops you from silently mixing a latent into a video collection - but it means the port you wire first decides what the whole run can be.

Second, it detects the type per stage, so unlike the single variant you don't have separate typed sockets - just the wildcard value_N ports. If the kind is video, each stage's segment is saved as a clip and the final merge stitches them with audio; any other kind gets batched (tensors stacked along the frame/batch axis).

Inputs and outputs

Input: stage_info (from flow_stage_begin) plus value_1…N. Outputs: image_batch, mask_batch, latent_batch, merged_video, merged_audio. It's an output node with a UI status line, and it uses the always-rerun IS_CHANGED → NaN idiom so stale merges can't get cached.

Which one do you reach for?

Use collect_multi when each stage's generator is a separate node with a stable output socket - you get a clean 1:1 mapping of stage → port. Use collect_single when you're looping the same node per stage, or when you're not sure how many stages you'll end up with and don't want to re-wire ports. A good rule of thumb: if your stages all pass through one repeated subgraph, single; if they fan out into distinct branches, multi.

Install

Part of ComfyUI-Apt_Preset: ComfyUI Manager → "ComfyUI-Apt_Preset", or clone into custom_nodes and run install.bat, then restart. No models, no heavy deps. The trap to watch is the type lock - decide what you're collecting before you wire value_1, and keep every stage feeding the same kind.