[GH-ISSUE #3209] restore-snapshot silently skips a node when the snapshot's git URL no longer matches the node list #1119

New issue

Open

opened 2026-10-27 21:25:56 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-27 21:25:56 +00:00

Owner

Originally created by @kmj00204 on GitHub (Aug 26, 2026).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/3209

restore-snapshot silently skips a node when the snapshot's git URL no longer matches the node list, no error at all

I have a snapshot with this entry in git_custom_nodes:

"https://github.com/WASasquatch/was-node-suite-comfyui.git": {
    "hash": "ea935d1044ae5a26efa54ebeb18fe9020af49a45",
    "disabled": false
}

That's the original author's repo. It still exists and clones fine on its own with a plain git clone. But custom-node-list.json doesn't point there anymore — it's now https://github.com/ltdrdata/was-node-suite-comfyui (id was-ns, the description even says it's the replacement pack after the original author retired).

When I run restore-snapshot on this snapshot, every other node in it (about 39) installs fine, each with the usual Download: git clone '...' + Install: pip packages output. This one node never gets a clone line, never prints an error, nothing — it just shows up at the very end as:

[  FAILED   ] was-node-suite-comfyui

If I edit the snapshot to point at the ltdrdata fork instead (with the matching hash), the exact same restore-snapshot run installs it like any other node. So the repo itself was never the problem — the URL in the snapshot just doesn't match anything in the current node list anymore.

Happened the same way on three separate fresh instances, so it's consistent, not a fluke.

I dug into restore_snapshot() in glob/manager_core.py a bit. There's a loop that looks up each git URL in unified_manager.repo_cnr_map, and if it doesn't find a match (cnr is None), there's no else — it just moves on without installing, without erroring, and without marking it processed. From reading the code, I'd expect it to still fall through to the later loop that clones any leftover URL directly, but that doesn't seem to happen in practice — I couldn't fully trace why before the entry drops out. Might be something upstream in reload()/get_custom_nodes() that removes it earlier, not sure.

Either way, the real issue is that this fails completely silently. There's no way to tell from the output whether a node's install was attempted and failed, or just never looked at. Some kind of explicit message for the "couldn't resolve this URL to anything" case would've saved a lot of debugging time — I only found the actual cause by grepping the cached node list myself.

ComfyUI-Manager commit: f39cbd56fe

Originally created by @kmj00204 on GitHub (Aug 26, 2026). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/3209 # restore-snapshot silently skips a node when the snapshot's git URL no longer matches the node list, no error at all I have a snapshot with this entry in `git_custom_nodes`: ```json "https://github.com/WASasquatch/was-node-suite-comfyui.git": { "hash": "ea935d1044ae5a26efa54ebeb18fe9020af49a45", "disabled": false } ``` That's the original author's repo. It still exists and clones fine on its own with a plain `git clone`. But `custom-node-list.json` doesn't point there anymore — it's now `https://github.com/ltdrdata/was-node-suite-comfyui` (id `was-ns`, the description even says it's the replacement pack after the original author retired). When I run `restore-snapshot` on this snapshot, every other node in it (about 39) installs fine, each with the usual `Download: git clone '...'` + `Install: pip packages` output. This one node never gets a clone line, never prints an error, nothing — it just shows up at the very end as: ``` [ FAILED ] was-node-suite-comfyui ``` If I edit the snapshot to point at the `ltdrdata` fork instead (with the matching hash), the exact same restore-snapshot run installs it like any other node. So the repo itself was never the problem — the URL in the snapshot just doesn't match anything in the current node list anymore. Happened the same way on three separate fresh instances, so it's consistent, not a fluke. I dug into `restore_snapshot()` in `glob/manager_core.py` a bit. There's a loop that looks up each git URL in `unified_manager.repo_cnr_map`, and if it doesn't find a match (`cnr is None`), there's no `else` — it just moves on without installing, without erroring, and without marking it processed. From reading the code, I'd expect it to still fall through to the later loop that clones any leftover URL directly, but that doesn't seem to happen in practice — I couldn't fully trace why before the entry drops out. Might be something upstream in `reload()`/`get_custom_nodes()` that removes it earlier, not sure. Either way, the real issue is that this fails completely silently. There's no way to tell from the output whether a node's install was attempted and failed, or just never looked at. Some kind of explicit message for the "couldn't resolve this URL to anything" case would've saved a lot of debugging time — I only found the actual cause by grepping the cached node list myself. ComfyUI-Manager commit: f39cbd56fecae0b27a446c0cd450cd591f3a8bea