_.reduceRight

_.reduceRight is _.reduce folded from the other end: it walks the collection last-to-first, accumulating as it goes. Same idea, mirrored direction. In practice the direction rarely matters for sums or concatenations - but the function signature is where this node will bite you, because it doesn't match its sibling's.

How it works

Under the hood the port reverses the list and runs Python's functools.reduce over it. The important mechanical difference: _.reduce calls your function with three arguments (memo, value, index), but _.reduceRight calls it with two (memo, value). I verified it - a three-argument lambda that works fine in _.reduce throws missing 1 required positional argument here. If you copy a combine function from a reduce workflow into reduceRight, it'll fail on the first run.

Inputs:

• list_or_dict - the collection (or a _.CHAIN)
• memo - the starting accumulator

Output: the folded result.

The memo behaves differently here

Here's the counterintuitive flip: reduceRight is actually more forgiving about the memo than reduce is. If you leave it unplugged, it falls back to functools.reduce with no initial value, which uses the first element it sees as the starting accumulator and never calls your function on it. That works fine with a two-argument combine function. So the node that reads "right" in the name is the one where the missing memo is less likely to explode on you.

Still, for anything you want to be explicit and predictable, supply the memo. Same advice as the sibling: bring your own starting value.

The callable requirement

Like _.reduce, this needs a function from somewhere - a lambda/function node from another pack, or the pack's underscore function export. There's no widget that can type a combine function. And it must accept exactly two arguments. If you're not already feeding callables through your graph, this node is a hard pass; the family's list utilities cover most "combine a list" needs more directly.

When direction actually matters

For sums, string concatenation and most tallies, left-to-right and right-to-left give the same answer. Direction matters when the combine function is non-associative - subtraction, division, building a string in reverse order, or any fold where the order of operands changes the result. If you find yourself needing [1, 2, 3] reduced as 1 - (2 - 3) rather than (1 - 2) - 3, this is the node.

Installing

Part of comfy-ovum. ComfyUI Manager → search comfy-ovum → Install, or:

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

Restart ComfyUI. No models, no extra pip packages for the underscore nodes - the port is bundled in the repo.

The bottom line

Right-to-left folding, and the trap isn't the direction - it's that the combine function takes two arguments here, not three. Get that right and the missing memo is a non-issue.