Batch Extend Ovum

This is the "comfy-style" list extend: feed it two lists, get back one list that's the first followed by the second. In Python terms it's list_a[:] + list_b - a fresh list, so neither input is touched. It's the kind of node you barely notice until you're stitching together batches of prompts, seeds, or image paths from multiple sources and you realize how often "combine these two collections" comes up.

It lives in the ovum/lists/comfy category, which in this pack means the node is list-aware at the graph level: the output is flagged as a list (is_list: true), so ComfyUI's type system treats the result as a collection that downstream list consumers can accept. That's the whole distinction between this and its cousin ConcatBatchesOvum in the same folder - that one wraps non-list values into lists for you, where this one is stricter.

The inputs

• list_a (*) - first list.
• list_b (*) - second list.

Output is a single list (*) - the concatenation. Both inputs must be actual Python lists; the node raises a clear error if you hand it a string or a number instead. If you need to be sloppy about types, use ConcatBatchesOvum instead.

When you'd reach for it

• Combining two batches of prompts for a big variation run.
• Appending a "common" list of negative prompt terms to a per-image list.
• Merging seed lists from two sources into one sampling pass.

Because it's non-mutating, you can chain multiple BatchExtend nodes safely - each one is a pure function of its inputs, which is exactly the behavior you want in a graph that re-evaluates and caches.

Installing it

Part of comfy-ovum:

cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum

Restart, or ComfyUI Manager → search "comfy-ovum". No models, no heavy dependencies - just the pack's usual light requirements.

Gotchas

The strictness is the gotcha. Hand it a single string thinking it'll be treated as a one-item list and it raises. If your data isn't reliably a list, normalize it upstream or use the ConcatBatches variant, which tolerates scalars by wrapping them. And if both inputs are empty or unset, you get an empty list - harmless, but easy to mistake for a bug when the output "looks" empty downstream.