WorkflowX_DetailerXReplay
DetailerX's do-over, running without your generator
- final_image
- processor_images
- detailer_masks
Rerun on DetailerX is a small magic trick: change a denoise value, click the button, and get a new image without regenerating the base. WorkflowX_DetailerXReplay is the node doing the actual work in the graph that gets queued when you click it.
What it is
You won't find this by browsing the menu for something useful. It lives in WorkflowX/Internal and it is a stand-in: when Rerun fires, the pack builds a fresh prompt containing only the DetailerX subtree, replaces the DetailerX node in that prompt with Replay, and points every link that used to come from upstream at a snapshot source instead. Replay then runs the same processing chain with the current settings and hands the nine images back to the same downstream nodes you already had wired.
Because it's an output node, it's also the thing that queues: this is why a rerun runs the detailer and its downstream branch and nothing above it.
Inputs and outputs
Three required inputs:
token(STRING) - the retained DetailerX session whose inputs are being reused.settings(STRING) - the JSON settings to apply, normalized server-side before use.job(STRING) - the rerun's job id. It's checked against the session, which is how a stale request gets rejected instead of quietly re-running with yesterday's state.
Outputs are the same nine IMAGE sockets DetailerX has, in the same order: upscaler_image, face_detailer_image, breast_detailer_image, pussy_detailer_image, hand_detailer_image, foot_detailer_image, realism_detailer_image, dlss5_image, final_image. If Skip is enabled, every output is a clone of the retained input image - the detailer bypasses itself on reruns too.
It also writes the effective settings into the prompt and PNG metadata under detailer_x_effective, so a rerun's output is traceable back to the values that made it. That's a nice touch, and it matters more than it sounds: the whole reason detailers have a bad reputation for unreproducibility is that nobody records what the repair pass actually ran at.
What Rerun does and doesn't do
- Does: reuse retained model, CLIP, VAE, image and conditioning - no upstream execution.
- Does: apply the settings currently on the node, including toggles you flipped after the original run. Apply open gear dialogs first; unapplied drafts are excluded.
- Does: preserve stage-cache reuse for stages whose inputs didn't change, so re-running with one stage tweaked doesn't recompute the rest.
- Doesn't: see upstream edits. New prompt, new seed, new checkpoint - none of it lands until you queue the ordinary workflow.
- Doesn't: stop downstream nodes re-running. Your savers will write extra files, with a fresh counter each time.
- Doesn't: overlap with the original job. Rerun stays disabled until the originating workflow finishes.
Install and troubleshooting
Nothing to install separately - it arrives with the pack:
cd ComfyUI/custom_nodes
git clone https://github.com/haroonaslam/WorkflowX-Configurator
python -m pip install -r WorkflowX-Configurator/detailer_x/requirements.txt
Restart ComfyUI afterwards; the rerun route and the prompt handler that injects the capture nodes are registered at startup, so a hot-reloaded frontend against a stale backend won't line up.
Failure messages you might actually see, and what each one means:
- "Rerun session is stale; queue from the DetailerX toolbar again." The session's queued job id doesn't match this request - the server restarted, the session was evicted, or a newer rerun superseded it.
- "Wait for the current workflow to finish before rerunning." Overlapping GPU work is refused on purpose.
- "No retained input for <node>.<input>." A link crossing into the subtree wasn't captured when the original run queued. Queue normally once.
- "Rerun graph is not supported: …" ComfyUI's own prompt validation rejected the rebuilt graph - usually a dynamically resolved mapping or a node whose descendants the pack can't enumerate. Queue the full workflow.
- "DetailerX retained inputs exceed the shared 2 GiB limit." The CPU snapshot store is full. Batch smaller, or clear out paused sessions.
- DLSS5 stage during a rerun. Native runtime preparation happens again on each replay; on hardware without a compatible NVIDIA driver, disable the stage rather than retrying.
One more thing worth knowing: if the original run was a tensor batch, only that batch is replayed. Rerun is a re-do of the pixels you already have, not a hook for feeding it something new - for that, wire fresh inputs and queue normally. The write/read pair behind it is documented on the Capture and Snapshot pages.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| token | STRING | — | |
| settings | STRING | — | |
| job | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| final_image | IMAGE | — |
| processor_images | DETAILERX_PROCESSOR_IMAGES | — |
| detailer_masks | DETAILERX_MASKS | — |