ComfygQueueTrigger

Let's get the honest framing out of the way first: the pack's own README says, in the author's words, "Ignore the ComfygQueueTrigger node, I'm still working…" So this is an experimental node, and you should treat it like one. That said, the idea behind it is genuinely useful, so it's worth knowing what it does and - more importantly - where it breaks.

ComfygQueueTrigger is the sibling of ComfygQueue. Where ComfygQueue is a self-contained sampler loop, Trigger reaches into the workflow that's currently executing and re-queues the whole thing once per resolution. It generates nothing itself. It's a queue manipulator: your full pipeline - whatever you built around your samplers - runs at every resolution in your list, with the node rewriting the size and seed between runs.

How it works

The node reads the hidden prompt (the API-format snapshot of your current graph), scans it for every node with class_type KSampler and every EmptyLatentImage, and for each resolution in res_presets:

• deep-copies the workflow,
• overwrites width/height on all the EmptyLatentImages and seed on all the KSamplers,
• then either queues that copy or just returns its data.

That last part is the execution_mode dropdown. queue_multiple validates each modified workflow and pushes it onto the prompt queue - the jobs appear in your queue as if you'd queued them by hand, with a 0.05s pause between enqueues so it doesn't choke the server. return_data_only skips the enqueue entirely and just hands you the job list as JSON.

Seed handling: batch_seed: -1 rolls a fresh random seed per job; a fixed seed becomes seed + i per job when modify_seeds is on. That's the whole input surface - just four widgets: res_presets, batch_seed, execution_mode, modify_seeds. No model, no VAE, no prompt inputs; it runs whatever your graph already contains.

Outputs

Two STRING outputs. status is a human-readable summary of what was queued or prepared, and queue_data is the JSON array of jobs - each with its resolution and seed. If you need the resolution/seed pairs for scripting or bookkeeping, that's the one to tap.

Where it falls apart

This is the part worth reading, because the failure modes are structural, not random.

• It only recognizes nodes literally named KSampler and EmptyLatentImage. KSamplerAdvanced, an SD3/Flux latent node, or any wrapper pack that hides the sampler inside it → silently ignored. If neither type exists in the graph, you get "Missing KSampler or EmptyLatentImage nodes" and nothing happens.
• It rewrites every matching node. A two-pass hires workflow has two samplers and possibly two latents - both samplers get the same new seed, and both latents get resized to the target. For the second pass that's usually the opposite of what you want (that's what denoise and a fixed latent are for). Realistically this is built for single-sampler workflows.
• It enqueues by pushing directly onto the prompt queue via its own validator rather than the normal frontend path. It works when the queue is quiet; it's the kind of queue manipulation that gets unpredictable when you already have jobs running.

Installing it

Same install as ComfygQueue - they ship in one pack. ComfyUI Manager: search "comfyg-queue" and install, then restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/guerreiro/comfyg-queue

Then restart ComfyUI. No requirements.txt, no pip dependencies - it's pure ComfyUI core calls.

Bottom line

If you want the "run this entire graph at 1024², then 1152×896, then 896×1152" pattern, Trigger is the idea, and the idea is good. But the author himself is still working on it, it only sees stock KSampler/EmptyLatentImage nodes, and it'll happily mangle a multi-sampler graph. Expect WIP-level polish and keep it to simple workflows.