Model Cache Corruption Can Break LoRA Manager

[small-round-object]

LoRA Manager Version

• Version: v0.9.11

Issue Description

• If there is a write issue, crash, or the drive fills while LoRA manager is writing to the cache this can break the LoRA cache.

Steps to Reproduce

Corrupt the LoRA cache and try to load LoRA manager.

Expected Behavior

There should be a check to see if the cache is not loading correctly/corrupted and an auto-rebuild should take place as a fallback.

Logs

Errors look like: LoRAs do not show thumbnails/do not show up in the main window.

Temporary Patch to resolve issue

Note: This is only a temporary workaround, not a proper fix.

• Comment out line 827 of custom_nodes\comfyui-lora-manager\py\services\model_scanner.py
• Change line 26 of custom_nodes\comfyui-lora-manager\py\services\lora_service.py to: "model_name": lora_data.get("model_name", "CORRUPT_FILE"),
• Restart, refresh LoRAs
• Manually remove any LoRAs that still refuse to load thumbnails and delete their metadata.
• Return both edited files to their original configuration
• Reimport LoRAs that were removed

Suggested full fix

1.) Update the format response method of lora_service.py so that if data is bad, it reports failure (returns None).):

2.) Update the list comprehension in model_handlers.py to filter out the None values returned by the new lora_service.py logic:

[Ainaemaet]

Why do they even have this stupid Lora caching nonsense??? What about those of us who have very large model collections??

[willmiao]

Why do they even have this stupid Lora caching nonsense??? What about those of us who have very large model collections??

It’s not caching the model files themselves, but a snapshot of the metadata for all models. Even with very large collections, this is usually only a few dozen MB.

This cache is specifically designed for large collections—it can reduce startup time from minutes (when loading metadata from scratch) to almost instant. Occasionally the snapshot can become invalid, in which case a manual Rebuild cache is needed. Improving this behavior is something I’m actively working on.

I’m always open to feedback, but I’d appreciate a more constructive tone in future discussions.

[scruffynerf]

I've seen this bug as well....
and yes
one 'needed' fix is the change the model_name line to a get...
Change line 26 of comfyui-lora-manager\py\services\lora_service.py to: "model_name": lora_data.get("model_name", "CORRUPT_FILE"),

Right now it's a direct ["model_name"] and if that's broken, it fails hard. A get is used elsewhere, and really, probably should be used in a few other places.

[druidican]

Why do they even have this stupid Lora caching nonsense??? What about those of us who have very large model collections??

It’s not caching the model files themselves, but a snapshot of the metadata for all models. Even with very large collections, this is usually only a few dozen MB.

This cache is specifically designed for large collections—it can reduce startup time from minutes (when loading metadata from scratch) to almost instant. Occasionally the snapshot can become invalid, in which case a manual Rebuild cache is needed. Improving this behavior is something I’m actively working on.

I’m always open to feedback, but I’d appreciate a more constructive tone in future discussions.

Would it be feasable to make a funktion that erases all data except *.safetensors, so that a completly clean rebuild can be made ?
I have found that if you have multiple *-nfo and img from former versions of a lora or checkpoint it can corruup or prevent lora manager and chepoint loaders from recogniseing files

[willmiao]

Would it be feasable to make a funktion that erases all data except *.safetensors, so that a completly clean rebuild can be made ?
I have found that if you have multiple *-nfo and img from former versions of a lora or checkpoint it can corruup or prevent lora manager and chepoint loaders from recogniseing files

That shouldn’t be necessary. When this issue occurs, it’s usually caused by a corrupted metadata snapshot in the database, not by leftover images, or .metadata.json sidecar files.

That’s why using Rebuild Cache (available from the Refresh button’s dropdown) resolves the issue—it reloads metadata from all existing .metadata.json files and rebuilds the database cleanly.

Manually deleting sidecar files is actually strongly discouraged, since you’ll lose all your metadata in the process.

[hypnichorse]

This issue still persists, even in newer versions, making these nodes utterly unusable for me.
None of the fixes above work for me.

[ash-bluepollution95]

Yea this honestly just happened last night, on a FRESH install, FRESH b atch of loras i downloaded from my HF that i trained in the last week- ComfyUI is meant to be so much "EASIER" but this node as nice as it's A11 compat it's ... annoying when the ONE bug isnt' fixed..

I can tolerate the "doesnt know about HF" issue that i closed, that's understandable (frustrating to me personally but hey people from civit REALLY love this lol) -- but this is a deal breaker, this is months old and should've been fixed.

[willmiao]

@duskfallcrew Hi, thanks for the feedback, and sorry about the issue.

There have been several related commits attempting to fix this, but since the issue only reproduces for some
users (I wasn't able to reproduce it on my end) and a cache rebuild seems to resolve it for others, I've been
relying on user feedback to confirm whether it's actually fixed. That's why the issue stayed open, not because I
was ignoring it.

That said, it's on me that I didn't take a more proactive approach sooner. I just did a thorough scan of the
logic that could be causing this, and I'm hopeful the issue is now resolved.

Regarding the (batch) HuggingFace download you suggested in the other thread, it's nearly ready and will be
included in the next release. Thanks for the suggestion there, and feel free to give it another try when it
ships.