WorkflowX_DetailerXSnapshot

This is the other half of the DetailerX rerun trick. WorkflowX_DetailerXCapture writes boundary values down; WorkflowX_DetailerXSnapshot reads them back out and hands them to the re-executed subgraph as if your generator had just produced them.

What it is

When you hit Rerun on DetailerX, the pack rebuilds a small prompt containing just the detailer subtree, swaps the detailer itself for the replay node, and rewires every link that used to come from outside that subtree to a Snapshot node instead. Upstream nodes are not in that rebuilt graph at all - which is the entire point. No checkpoint reload, no sampler pass, no VAE decode of a generation you already have.

You will never place this node yourself and it will never appear in your saved workflow. It exists only inside the throwaway graph that Rerun queues.

Inputs and output

Three required inputs, one wildcard output:

• token (STRING) - the retained session to read from.
• key (STRING) - the link that was tapped, matching the key its Capture node recorded.
• job (STRING) - the rerun's job id, used only to namespace the node ids inside the rebuilt prompt so two concurrent replays can't collide.
• output * - the retained value, re-emitted for the consumer that needs it.

The output is list-mapped, mirroring the Capture side, because the entry layer runs in the list context the executor hands it. What comes back is a detached CPU clone, so a rerun can't alias memory the previous execution is still using - and if you wired a model link, that's a reference to the same patcher object, not a second copy of 12GB of weights.

What it means in practice

A rerun is a snapshot of the moment you queued, not a live re-read of your graph. Edit the prompt upstream of DetailerX, hit Rerun, and nothing changes: that text was baked into the conditioning at capture time. The only way to pick up upstream changes is to queue the ordinary workflow. DetailerX's doc is honest about this and so is the button's own tooltip. If that sounds like a limitation, it's the trade for not spending a full generation to test one denoise value.

Downstream nodes run again. Everything above the detailer is skipped; everything below it isn't. Savers will happily write you another file with the same prefix and a new counter. If you rerun five times while tuning, expect five files.

Boundaries are validated, not guessed. Before the rerun graph is queued it's run through ComfyUI's own prompt validation, and the pack checks that each boundary source still has the same class_type as when it was captured. If it doesn't, the rerun fails with "Boundary source changed type" instead of feeding something nonsensical into a socket.

Install and gotchas

No install beyond the pack itself - Clone it, install the detailer requirements, restart, refresh:

cd ComfyUI/custom_nodes
git clone https://github.com/haroonaslam/WorkflowX-Configurator
python -m pip install -r WorkflowX-Configurator/detailer_x/requirements.txt

Things that actually bite:

• "No retained input for <node>.<input>. Queue the ordinary workflow to capture this connection." A connection was added after the last run, so no Snapshot entry exists for it. Queue normally once.
• "DetailerX mapping changed or is dynamically expanded. Queue the ordinary workflow." The rebuilt subgraph didn't line up - usually after you edited the DetailerX node's own wiring, or with a node whose descendants resolve dynamically.
• Rerun button greyed out. The session's can_rerun is false while the originating job is still running, or after the retained inputs were evicted. Wait for the queue to drain, or queue the workflow again.
• Server restarted. Sessions, tokens and snapshots are in-process state and do not survive a restart. The workflow file still holds your Pause/Skip toggles; everything runtime-only is gone.

Treat the whole Capture/Snapshot pair as one mechanism: capture at queue time, snapshot at rerun time, both invisible, both bounded by a 2 GiB CPU budget the pack enforces on itself. If you run long batches with several paused jobs, that budget - not your VRAM - is the limit you'll hit first.