Changing model type does not move the underlying file to the new model folder
- Dominant language
- Python
- Stars
- 133k
- Forks
- 15.7k
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 158
Description
## Summary
Changing a model asset's type after upload updates tags/metadata, but does not move the physical file to the folder for the new model type.
This leaves ComfyUI in an inconsistent state:
- the asset can appear to be type `detection`
- but the actual file still remains under the original folder such as `models/onnx`
- nodes that enumerate files from `models/detection` cannot see it
## Why this matters
Some custom nodes register their own model folders and read files directly from those folders via `folder_paths.get_filename_list(...)`.
A concrete example is custom nodes that register:
- `folder_paths.add_model_folder_path("detection", os.path.join(folder_paths.models_dir, "detection"))`
Their loaders expect files to exist under:
- `ComfyUI/models/detection`
If a user uploads a `.onnx` file as `onnx`, then later changes the model type to `detection` in the asset UI, the UI suggests the asset is now `detection`, but the file is still physically in `models/onnx`.
As a result:
- the asset browser metadata and tags imply one type
- the actual node dropdowns still cannot find the file
## Current behavior
From the current backend flow:
- new uploads resolve destination from `tags` using `resolve_destination_from_tags(tags)`
- existing assets go through `_register_existing_asset(...)`
- `_register_existing_asset(...)` updates references / metadata / tags, but does not move the underlying file
In a real reproduced case, this also led to a second inconsistent state:
- the active reference selected in the UI had `file_path = null`
- another reference with the same `asset_id` still pointed to the real file
- that sibling reference was soft-deleted (`deleted_at` set)
- so the asset effectively still existed on disk, but the active reference no longer had a materialized file path
That means the problem is not only "type changed but file stayed in the old folder".
It can also create asset/reference states where:
- one reference still owns the physical file in the old folder
- the active reference only carries newer tags/metadata
- operations that act on the active reference cannot safely reclassify the asset because there is no live file path on that active row
## Expected behavior
When a model asset's effective model type changes from one folder-backed type to another, ComfyUI should provide a supported way to reclassify it by:
- moving the physical file into the destination folder for the new type
- updating the active reference `file_path`
- updating filename metadata to match the new location
- keeping the asset metadata/tags and disk layout consistent
- avoiding situations where the active reference has no file path while a soft-deleted sibling still owns the only materialized file
## Minimal repro
1. Upload an ONNX model so it is stored under `models/onnx`
2. Change its model type to `detection`
3. Open a custom node that loads from `models/detection`
4. The file is not available, because it was never moved
A stronger variant of the repro is when repeated import/reclassification leaves:
- one active reference with updated tags but no `file_path`
- one soft-deleted sibling reference with the actual file still present in the original folder
## Additional note
This is not just a display-name issue. The asset browser can show a new type via metadata/tags, while model loaders still depend on the actual file system location.
Contributor guide
Assessment
This issue has not been assessed yet.