List Bridge

ComfyUI's list execution has a subtlety that trips people up: a list output doesn't necessarily mean "all items are ready" before the next node starts consuming them. List Bridge exists specifically to fix that. Per the pack's own description, "when passing the list output through this node, it collects and organizes the data before forwarding it, which ensures that the previous stage's sub-workflow has been completed." In plain terms: it's a synchronization point. Route a list through it, and everything upstream that produces that list is guaranteed to have actually finished before anything downstream of the bridge starts running.

Why this needs to be a separate node

If you've built a sub-workflow that produces a list - say, a batch of detected regions each running through their own little processing chain - and the next stage depends on the whole list being complete (not just some items trickling in), you can hit timing issues where downstream nodes start acting on a partially-built list. List Bridge collects everything from the upstream sub-workflow first, then forwards the assembled, complete list onward. It's a small node, but it's solving a real class of "why did this run before that finished" bug that's otherwise hard to diagnose in a list-heavy graph.

The input and output

• list_input (required, wildcard *) - the list to bridge. Wildcard-typed, so it works with a list of images, latents, SEGS, numbers - whatever your sub-workflow is producing.

Output is list_output - the same data, explicitly flagged as a list, released only once collection is complete.

Because both sides are typed *, this node is one of the ones covered by the README's own limitation note on wildcard typing: "This approach will be replaced once ComfyUI officially supports dynamic types. Until then, while it functions without issues, type validation may still produce error messages." A red type-warning on a List Bridge connection that otherwise runs fine is this known quirk, not a sign your graph is actually broken.

How to install it

Via ComfyUI Manager: search ComfyUI Impact Pack, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Pack comfyui-impact-pack
cd comfyui-impact-pack
python -m pip install -r requirements.txt   # ComfyUI's python; python_embeded on portable

then restart. No models, no extra dependencies - pure execution-ordering plumbing.

Common issues & troubleshooting

Downstream node is acting on incomplete or stale-looking list data. This is exactly the symptom List Bridge is built to fix. Insert it between the list-producing sub-workflow and whatever consumes the list next, so consumption only begins once the whole list is actually assembled.

A type-mismatch warning appears even though the graph runs correctly. That's the wildcard-typing limitation the README calls out directly - cosmetic, not functional, given the current state of ComfyUI's type system.

Do you actually need this? Most simple list flows (a list producer feeding straight into a list-consuming node) don't need a bridge - ComfyUI's normal list execution handles them fine. Reach for List Bridge specifically when your list comes out of a more complex sub-workflow with its own internal branching or looping, and you've observed or suspect a timing issue where downstream work starts before the list is genuinely complete.