Why ComfyUI “Randomly” Breaks After an Update
One of the most frustrating ComfyUI experiences goes like this: everything was working yesterday, you ran an update, and suddenly the same workflow that produced clean images now throws a confusing error — often something about float16 and float32 not matching, or an operation that “expected half” but “got float”, or a node silently returning zeros and producing black output.
The instinct is to blame ComfyUI core. In most cases, that instinct is wrong. ComfyUI itself is a stable, well-tested base. What breaks is almost always a custom node that sits on top of it — a plugin whose author has not yet caught up with a change in ComfyUI’s internals, or a plugin that patches model precision in a way that conflicts with newer inference paths.
This article walks through a concrete, repeatable diagnostic workflow for finding which custom node broke your install and neutralizing it, so you can stop reinstalling ComfyUI from scratch every time an update changes the ground under your feet.
Read the Startup Log Before Touching Anything
The single most valuable diagnostic artifact you already have is ComfyUI’s console output at startup. Custom nodes load during boot, and when one fails to import cleanly, ComfyUI usually prints an explicit (IMPORT FAILED) marker followed by the node package path and the underlying Python traceback.
The pattern looks similar to this:
### Loading: ComfyUI-Custom-Scripts (x.x.x)
### Loading: ComfyUI-FreeU (y.y.y)
(IMPORT FAILED): /path/to/ComfyUI/custom_nodes/ComfyUI-FreeU
Traceback (most recent call last):
...
AttributeError: module 'comfy.samplers' has no attribute 'FreeU2'
An (IMPORT FAILED) line is a smoking gun. The node package listed right after it could not be initialized at all, which means every node it provides is missing from your workflow — often causing “invalid node type”, “type undefined”, or the model-loading error you later see when a required node simply never registered.
If you are on a desktop install, launch ComfyUI from a terminal and scroll the boot output. If you run headless through a service, check wherever stdout is captured (your supervisor or systemd journal). Do not skip this step — many people spend hours re-downloading models when the answer was already printed on line 30 of a log they never read.
The dtype-mismatch Error Is Usually a Plugin, Not a Model
A specific class of error that surfaces after updates is a dtype mismatch: messages reporting that a float16 tensor was passed where float32 was expected, or that an operation “could not be run with the given precision.” Users frequently assume this means their checkpoint is corrupted or the wrong precision variant was downloaded.
In practice, this kind of error is often the signature of a custom node that hooks into the sampling or model-loading pipeline and assumes a fixed precision. A documented example is FreeU variants: the advanced FreeU nodes patch model weights during sampling, and if they were written against an older ComfyUI patch system, an update that changes how those patches are applied can surface as a confusing dtype error rather than a clean crash. The fix reported by users was not “downgrade your model” but “remove the stale plugin” — after which generation worked again. If you are new to local AI, our guide to running the ComfyUI VRAM launch flags explains how --lowvram and --normalvram interact with exactly these model-loading paths.
The general lesson: if a workflow ran fine on one model precision and now throws dtype errors after an update, suspect the nodes that touch the model or sampler. Bisect them before you touch the model files.
Bisect custom_nodes to Isolate the Culprit
ComfyUI loads every folder under custom_nodes/, so the fastest isolation technique is a binary search over those folders rather than guessing one by one. (The official ComfyUI docs on custom nodes confirm that any directory placed there is auto-imported at startup, which is exactly why a bad plugin can take down otherwise-healthy workflows.)
A reliable approach:
- Snapshot a known-good baseline. Move every custom node folder into a temporary directory outside
custom_nodes/so ComfyUI boots with zero plugins. Confirm the core UI loads and a trivial built-in workflow (e.g. empty-latent-image to KSampler) runs. This establishes that core itself is healthy. - Re-add in halves. Move half the folders back, restart, and load your broken workflow. If it fails, the culprit is in that half; if not, move the other half back.
- Recurse. Keep halving the responsible set until you reach a single folder.
You can also use ComfyUI-Manager rather than moving folders manually. ComfyUI-Manager (from the official Comfy-Org/ComfyUI-Manager repository) lists installed custom nodes and lets you disable or enable them from the UI, and it surfaces import errors and available Git updates for each package. Using its disable toggle for the same bisection is faster and avoids accidental folder damage, though the manual folder approach works even when Manager itself fails to load.
Key point: restart ComfyUI after each enable/disable change. Import-time failures and registration order are evaluated at boot, so toggling a toggle without restarting tells you nothing.
Fix It: Update, Pin, or Remove
Once you have identified the offending node, you have three realistic options, in order of preference:
- Update the node. Most actively maintained nodes ship a fix for a breaking ComfyUI change within days. Run the updater in ComfyUI-Manager, or
git pullinside the node’s folder. This is the strongest fix because you keep the functionality. - Pin to a compatible ComfyUI commit. If the node is abandonware but you genuinely need it, you can roll ComfyUI core back to the last commit that worked with it (using
git checkoutin the ComfyUI repo) and freezecustom_nodesupdates. This buys time but leaves you vulnerable to security and feature lag. - Remove or disable it. If the node is unused or has been superseded, disable it. A node you installed on a whim and never used is precisely the kind of plugin that quietly breaks the whole install later.
Resist the reflex to reinstall ComfyUI from scratch. A clean reinstall may temporarily remove the broken plugin, but if your workflows depended on it (or on any of the other nodes you lose), you will either reintroduce the bug or spend hours rebuilding state you could have preserved with a five-minute bisection.
Prevent It From Happening Again
A few habits make the next update painless:
- Keep a startup-log baseline. After a known-good boot, save the console output. The next time something fails, diff the new log against the baseline and look at what changed — usually an
IMPORT FAILEDor a new warning is the first clue. - Update deliberately, not eagerly. Do not blindly click “update all” in ComfyUI-Manager. Update core and nodes separately, test after each, and keep a mental note of which nodes you actually use so you can disable the rest.
- Prefer maintained nodes. Before installing a node, glance at its repository for recent commits and open issues mentioning the ComfyUI version you run. A node whose last commit is two years old is a time bomb on the next core update.
- Version-pin a working environment. For production or repeatable pipelines, snapshot the Git commit of both ComfyUI core and each custom node you depend on, so you can reproduce a working stack on demand.
ComfyUI’s flexibility comes from the custom-node ecosystem — and that ecosystem is also the most common source of “mysterious” post-update failures. Learning to read the boot log and bisect custom_nodes/ turns a day-long panic into a ten-minute cleanup.
Conclusion
When ComfyUI breaks after an update, the problem is rarely the model and almost never the base application. It is a custom node that no longer matches the version of core it was written for. Trace the (IMPORT FAILED) markers in your startup log, bisect the custom_nodes/ folder to isolate the culprit, then update, pin, or remove it. Treat a dtype-mismatch error as a sign to inspect the nodes touching your sampler and model loader — not as a reason to redownload checkpoints. Do this before you reach for the nuclear “reinstall everything” option, and you will recover faster and keep your working pipelines intact.
Leave a Reply