Execution Gate Control

Execution Gate Control is the kill switch for the Mickmumpitz pack's execution-gate system - and to understand why it exists, you have to meet the other two nodes it governs: CheckOutput and ExecutionGate. The pack lets you do multi-stage graphs (think "finish this subgraph, then let the downstream node proceed") by auto-wiring dependencies. CheckOutput signals "this subgraph is done." ExecutionGate blocks on that signal before releasing its value. Execution Gate Control is the single toggle that turns that whole waiting mechanism off, per channel.

It's the kind of node you won't touch in a simple workflow and can't live without in a complicated one. The use case: you've got a stage-A pipeline feeding a stage-B pipeline, and you want B to run only after A has genuinely finished. Without the gate system, ComfyUI's execution order may fire B early with stale data. With it, B waits. And when you're debugging - or you've wired a graph where you want B to run immediately regardless - one Execution Gate Control flips the behavior graph-wide, no rewiring.

How it works

It's a control node, not a data node: it has no outputs. The mechanism lives in the pack's prompt handler, which scans the prompt at submit time. It collects every CheckOutput and every ExecutionGate, groups them by their channel string, and then auto-injects hidden _check_N dependency slots into each gate pointing at all the CheckOutputs on the same channel. That's how the gate "knows" to wait. Execution Gate Control slots into the same pass: if a control on a channel has enabled set to false, the handler skips wiring that channel's gates entirely, so they pass through immediately. No control at all = gates behave normally. Set enabled to true = same as no control.

Channels are how you keep systems independent - "default" for the main gate chain, custom names for separate ones - so one control doesn't accidentally govern everything. Up to 10 CheckOutputs per gate get wired; beyond that, extras are ignored.

The inputs

• channel (default "default") - which gate system this control governs. Must exactly match the channel on the ExecutionGates and CheckOutputs you mean to control.
• enabled (default true) - false = gates on this channel stop waiting and pass through; true = normal gate behavior.

That's it. Two widgets, no outputs, and it's marked as an output node so ComfyUI actually executes it.

Installing it

Part of the Mickmumpitz pack - ComfyUI Manager, search "Mickmumpitz", install, restart:

cd ComfyUI/custom_nodes
git clone https://github.com/mickmumpitz/ComfyUI-Mickmumpitz-Nodes.git

No model downloads; the pack's base numpy/Pillow/opencv deps are all this needs.

Common issues

The classic gotcha is channel names. If your CheckOutput says "default" but your ExecutionGateControl says "stage_b", the handler treats them as unrelated systems and your control silently does nothing - the gates still wait. Typos in channel names are the most common "why isn't this working" report, and there's no error, just unexpected waiting. Second: because the wiring happens at prompt-submit time via a handler, the effect shows up on the next run, not retroactively - if you flip enabled mid-loop, it applies to the next enqueue. That's consistent with how the rest of the pack re-queues, but worth knowing.