ComfyUI ControlNetApplyAdvanced class_type Fix
Fix ComfyUI ControlNetApplyAdvanced class_type, node id has no class_type, and Apply ControlNet Advanced missing errors by separating workflow JSON, ComfyUI version, ControlNet models, and custom preprocessors.
If ComfyUI says ControlNetApplyAdvanced class_type, node id has no class_type, or a workflow opens with missing Apply ControlNet Advanced nodes, do not start by installing a Python package named ControlNetApplyAdvanced. That is a node class inside the workflow graph, not a package name.
The fastest safe path is: check whether the workflow JSON is valid, update ComfyUI if the workflow came from a newer install, then verify ControlNet models and any custom preprocessor nodes.
Fast answer
ControlNetApplyAdvanced is a ComfyUI ControlNet node. A class_type error usually means ComfyUI cannot read or resolve the node record in the workflow. Re-export the workflow or update ComfyUI before installing random packages.
Quick Diagnosis
| What you see | Likely meaning | First move |
|---|---|---|
ControlNetApplyAdvanced class_type | The workflow references a node class that this ComfyUI cannot resolve | Update ComfyUI, then reload the workflow |
node id has no class_type | The workflow JSON may be incomplete, corrupted, or exported by another tool | Re-export or recover the workflow from the original source |
| Apply ControlNet Advanced is missing from search | Old ComfyUI build, hidden/deprecated node path, or a cloud/managed environment difference | Check ComfyUI version and whether the environment exposes that node |
| Node exists but fails when queued | The node loaded, but its ControlNet model, image, or preprocessor input is wrong | Check models and runtime error text |
| Red nodes around preprocessors | A custom preprocessor pack is missing or failed to import | Install or repair the preprocessor custom node, not ControlNetApplyAdvanced |
What class_type Means
ComfyUI workflows are JSON graphs. Each node record needs a class_type so ComfyUI knows which node implementation to instantiate when it loads the graph.
When the error mentions class_type, the problem is often in the workflow graph or node registration layer. It is not automatically a missing Python package.
Step 1: Check Whether the Workflow JSON Is Broken
If the error says:
node id has no class_type. The workflow may be corrupted or a custom node is missing.open the workflow source again before changing packages:
- Download the workflow from the original source again.
- If it came from an image, try the original PNG, not a compressed JPG or social-media repost.
- If another tool exported it, re-export as ComfyUI workflow JSON.
- Try opening a simple built-in ComfyUI workflow to confirm your install still works.
If a simple built-in workflow also fails, this is broader than ControlNet.
Step 2: Update ComfyUI Before Adding Packages
ControlNetApplyAdvanced is documented as a ComfyUI built-in ControlNet node. If the workflow was made in a newer ComfyUI build, an older install may not understand the same node graph.
For a Git install:
cd ComfyUI
git pull
python -m pip install -r requirements.txtFor the official Windows portable package, run package updates from the portable root and use the bundled Python when installing requirements.
Step 3: Separate the ControlNet Node from ControlNet Models
The node and the model file are different things:
| Layer | Example | Repair path |
|---|---|---|
| Node class | ControlNetApplyAdvanced | Update ComfyUI or fix workflow JSON |
| ControlNet model | control_v11p_sd15_canny.pth or .safetensors | Put the model in ComfyUI/models/controlnet/ |
| Preprocessor node | Canny, Depth, OpenPose, LineArt | Install or repair the custom preprocessor pack |
| Runtime input | uploaded image, strength, start/end percent | Fix the workflow input values |
Do not download a ControlNet model when the real error is a missing class_type. Do not install a preprocessor pack when the real error is corrupted workflow JSON.
Step 4: If Apply ControlNet Advanced Is Missing
Try this order:
- Update ComfyUI.
- Restart ComfyUI completely.
- Search for
Apply ControlNet, not onlyControlNetApplyAdvanced. - Check whether the workflow uses a custom node pack such as Advanced-ControlNet or a preprocessor helper.
- If you are on a cloud or managed ComfyUI, confirm whether that environment exposes the same built-in and custom nodes.
What Not To Do
- Do not run
pip install ControlNetApplyAdvanced. - Do not reinstall every custom node pack before checking the JSON.
- Do not delete a working ComfyUI environment only because one downloaded workflow is corrupted.
- Do not confuse missing ControlNet model files with missing node classes.
How Wonderful Launcher Helps
Wonderful Launcher is useful when this error appears after importing a shared workflow: it can help keep separate ComfyUI environments, detect missing nodes and models, and preserve a working install before you update or repair plugins.
Download Wonderful Launcher if you want workflow import repair without guessing which layer broke.
Related Guides
- ComfyUI Missing Nodes, class_type, and Clean Library Entry Point Fix
- ComfyUI Workflow Red Nodes
- Install ComfyUI Custom Nodes
- Where to Put Safetensors in ComfyUI
- ComfyUI Failed to Save Workflow Draft
Source References
- ComfyUI ControlNetApplyAdvanced built-in node documentation
- ComfyUI workflow concept documentation
- ComfyUI ControlNet usage example
- Wonderful Launcher GSC query-page map, June 1-29, 2026:
comfyui controlnetapplyadvanced class_type
Start free with Wonderful Launcher if this affects your real ComfyUI environment. If the repair is blocking work, Agent Access is the paid guided path; credits are for image generation and metered tools.
Download Wonderful LauncherSee Agent AccessDid this fix your issue?
Your answer helps prioritize verified ComfyUI repairs.
ComfyUI "clean library entry point is missing" Fix
Fix the ComfyUI clean library entry point is missing error by checking workflow compatibility, frontend package drift, corrupted workflow JSON, and missing custom nodes.
Multi GPU
ComfyUI multi GPU setup for Windows and Linux: use --cuda-device to choose GPU 1, run two instances on separate ports, and avoid workflow-splitting assumptions.