π Conditional Splitter (nhk)
Send One Input Down Two Paths β Conditional Splitter (nhk)
- input
- pass_output
- fail_output
- info
Conditional Splitter (nhk) is the mirror image of the pack's Conditional Router. Where the router picks between two inputs, the splitter takes one input and, based on a boolean condition, sends it to one of two outputs - pass_output when true, fail_output when false. The output you don't pick is blocked, so only one downstream chain executes.
Think of the splitter as a railroad switch with a gate. It's for the shape of problem where you have a single value and two possible futures for it: "send this image to the upscale branch if it passed, or to the redo branch if it didn't." Same evaluation-driven workflow as the router, just organized differently on the canvas - one input fanning out to two pipelines instead of two inputs converging on one.
How it works
The gating is done with ComfyUI's ExecutionBlocker. When the condition is true, the node returns your input on pass_output and an ExecutionBlocker(None) on fail_output - a silent block that stops the fail chain without raising an error dialog, which is what keeps this batch-friendly. When the condition is false, the roles swap. Either way, exactly one output carries real data, and the inactive chain is pruned.
The info output tells you which output is active ("Routing to pass_output" / "Routing to fail_output"), also printed to the console.
Inputs and outputs
input- the value to route (any type).condition- boolean, default true. True = pass_output, false = fail_output.
Outputs:
pass_output- your input when condition is true (lazy - only executes if true).fail_output- your input when condition is false (lazy - only executes if false).info- a STRING saying which output is active.
Installing it
Same as the rest of the pack:
cd ComfyUI/custom_nodes && git clone https://github.com/Enashka/ComfyUI-nhknodes
restart, or "NHK Nodes" from ComfyUI Manager. It loads under nhk/wip.
Notes, straight from the WIP caveats
Because the blocking is silent, the failure mode is a quiet one: if something downstream of the blocked output still looks half-alive, remember a blocked chain just won't propagate - it doesn't error, and it won't save anything. And the standard pull-based gotcha applies: each output branch should end in a real terminal (a node with OUTPUT_NODE=True) or the branch may never get pulled into execution at all. If you wire a splitter and one side "does nothing," that's the usual cause. Also worth knowing: this node and the Conditional Router solve the same problem from different directions - splitter for one input into two pipelines, router for two inputs into one output. Pick the shape that matches your graph; there's no functional reason to prefer one beyond readability.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| input | * | Input to route to pass or fail output | |
| condition | BOOLEAN | true | True = route to pass_output, False = route to fail_output |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| pass_output | * | Input when condition is True, blocked when False |
| fail_output | * | Input when condition is False, blocked when True |
| info | STRING | Which output is active |