DonutCacheDebug

DonutCacheDebug is not a node you'll ever want in a production workflow. It's a debugging utility the Donut pack ships for its own sake: a single action dropdown with four options - enable_debug_logging, inspect_cache, test_cache_invalidation, and clear_cache - and one debug_output STRING on the other side. You drop it in, pick an action, run, and read what it says.

The context that makes it make sense: this pack does a lot of model caching - LoRA stacks, merges, and patches all cache model objects to avoid reloading and re-patching every run. Cache bugs are the classic horror story here: you change a LoRA's strength or swap a checkpoint, hit run, and ComfyUI hands you the old model because some cache key didn't invalidate. The pack even ships diagnostic scripts (debug_cache_invalidation_issue.py, fix_cache_model_identity.py) alongside this node - the author has clearly lived this bug. DonutCacheDebug is the user-facing way to see inside that machinery.

What each action does

• enable_debug_logging - turns on verbose logging for the cache layer so every cache hit/miss/invalidation shows up in the console. Start here; it's the least destructive and tells you what's actually happening.
• inspect_cache - prints what's currently in the cache: entry count and the first ~10 keys, truncated for readability.
• test_cache_invalidation - runs the pack's cache-invalidation test live and reports whether stale entries are being dropped correctly.
• clear_cache - empties the cache. The nuclear option, and the one that un-sticks you when a stale model is being served.

If your symptoms match - you changed a parameter, ComfyUI said "success," and the output looks identical to the previous run - that's cache serving you a stale model. Run test_cache_invalidation first to confirm, then clear_cache and re-run. You don't get to keep any state; the node is a pure instrument.

The honest verdict

This is a genuinely useful node for this pack specifically, and nearly useless outside it. It only sees the Donut pack's own cache, not ComfyUI's general model cache, so it won't debug a stale-model problem caused by some other custom node. If you don't run the pack's LoRA-stack or merge machinery, you'll never need it. If you do - especially if you stack several LoRAs and change them often - it's the difference between a 30-second clear_cache and an afternoon of head-scratching.

A caution from the mechanism side: clear_cache empties the pack's cache unconditionally, so if you're mid-experiment with a bunch of tuned models, be ready to re-patch. It's a debug node; it behaves like one.

Installing

Part of the pack: ComfyUI Manager → search DonutNodes, or git clone the repo into custom_nodes/ and pip install -r requirements.txt with the same Python that runs ComfyUI. No model downloads. And the useful habit: when a LoRA-stack workflow starts ignoring your changes, drop this node in, run test_cache_invalidation, and read the console before you tear your graph apart.