[PR #3210] fix(restore-snapshot): report failures and honor the pinned commit in the git fallback #3109

New issue

Open

opened 2026-10-28 21:15:13 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-28 21:15:13 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/ComfyUI-Manager/pull/3210
Author: @kmj00204
Created: 8/26/2026
Status: 🔄 Open

Base: main ← Head: fix/restore-snapshot-unresolved-git-url

📝 Commits (1)

8d894c5 fix(restore-snapshot): report failures and honor the pinned commit in the git fallback

📊 Changes

1 file changed (+13 additions, -2 deletions)

View changed files

📝 glob/manager_core.py (+13 -2)

📄 Description

Summary
The last loop in restore_snapshot() — the one that installs whatever git_custom_nodes entries are left after the CNR and unknown-node passes — has two problems:

It throws away the return value of repo_install() and appends the repo to cloned_repos unconditionally. A repo that failed to clone still gets printed as [ INSTALLED ] in the summary, and nothing shows up in failed.
It never checks out the commit stored in the snapshot. repo_install() clones the remote's default branch, so the restored node ends up on whatever HEAD happens to be, not the revision the snapshot pinned. Every other restore path in this function goes through repo_switch_commit(); this one doesn't.
The second one is the more annoying of the two in practice — you restore a snapshot expecting a specific revision and silently get a different one.

Fix
Check res.result before reporting success, and call repo_switch_commit() with the hash from git_info after a successful clone. Failures in either step are reported in failed with a message instead of being swallowed.

Test plan
Snapshot with a git entry not matched by the CNR/unknown passes, repo reachable — confirm it's cloned and checked out at the pinned hash
Same, but with an unreachable URL — confirm it lands in failed instead of [ INSTALLED ]
Same, but with a hash that doesn't exist in the repo — confirm the checkout failure is reported
Snapshot where everything resolves through CNR — confirm no behavior change

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/ComfyUI-Manager/pull/3210 **Author:** [@kmj00204](https://github.com/kmj00204) **Created:** 8/26/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/restore-snapshot-unresolved-git-url` --- ### 📝 Commits (1) - [`8d894c5`](https://github.com/Comfy-Org/ComfyUI-Manager/commit/8d894c5d244cb5dc75986606dc95835083b5909e) fix(restore-snapshot): report failures and honor the pinned commit in the git fallback ### 📊 Changes **1 file changed** (+13 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `glob/manager_core.py` (+13 -2) </details> ### 📄 Description Summary The last loop in restore_snapshot() — the one that installs whatever git_custom_nodes entries are left after the CNR and unknown-node passes — has two problems: It throws away the return value of repo_install() and appends the repo to cloned_repos unconditionally. A repo that failed to clone still gets printed as [ INSTALLED ] in the summary, and nothing shows up in failed. It never checks out the commit stored in the snapshot. repo_install() clones the remote's default branch, so the restored node ends up on whatever HEAD happens to be, not the revision the snapshot pinned. Every other restore path in this function goes through repo_switch_commit(); this one doesn't. The second one is the more annoying of the two in practice — you restore a snapshot expecting a specific revision and silently get a different one. Fix Check res.result before reporting success, and call repo_switch_commit() with the hash from git_info after a successful clone. Failures in either step are reported in failed with a message instead of being swallowed. Test plan Snapshot with a git entry not matched by the CNR/unknown passes, repo reachable — confirm it's cloned and checked out at the pinned hash Same, but with an unreachable URL — confirm it lands in failed instead of [ INSTALLED ] Same, but with a hash that doesn't exist in the repo — confirm the checkout failure is reported Snapshot where everything resolves through CNR — confirm no behavior change --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-28 21:15:13 +00:00