ComfyBuilder updates: define and implement a custom_nodes preservation policy

[Kosinkadink]

Split out of #1408. The urgent part of that issue (preserving ComfyUI/user across ComfyBuilder version updates, rollbacks, and crash recovery) is fixed on the PR #1404 branch. ComfyUI/custom_nodes is intentionally NOT preserved yet because the right policy needs a product decision from someone who knows what ComfyBuilder distributions are supposed to support.

Current behavior

The ComfyBuilder update transaction (src/main/sources/comfybuilder/index.ts) replaces the whole ComfyUI tree. ComfyUI/models and ComfyUI/user are detached before the swap and restored afterward; ComfyUI/custom_nodes is not, so node packs the user installed through Manager v4 (reachable: default launch args include --enable-manager) are silently deleted on every successful version update.

Why blind preservation is wrong

• Distributions can ship their own custom_nodes as part of the built artifact. Preserving the whole old directory would clobber or shadow distribution-shipped nodes on name collision, defeating the point of a curated build.
• User-installed node packs carry Python dependencies installed into the venv that the update just replaced. A preserved node pack may import against packages that no longer exist in the new venv, turning a clean update into a broken boot.
• A node pack may be incompatible with the new ComfyUI version itself.

Proposed starting point (needs owner sign-off)

On name collision the new distribution wins; user node packs absent from the new artifact are retained. Then either re-run their dependency install steps against the new venv, or surface a post-update report listing retained packs that failed to import so the user can reinstall them through Manager.

Open questions for the ComfyBuilder owner:

• Are users supposed to install extra node packs into a ComfyBuilder-managed install at all, or is the distribution the sole source of nodes? If the latter, the fix is to disable Manager pack installation for this route instead of preserving anything.
• If user packs are supported, who owns dependency re-resolution after a venv swap - desktop, Manager v4, or the builder manifest?
• Should retained packs be disabled by default until they import successfully against the new environment?

Acceptance criteria

• Policy decision recorded here by the ComfyBuilder owner
• Update/rollback/crash-recovery transaction implements the chosen policy with the same interleaving coverage as models/user preservation
• User-visible outcome (retained/dropped/disabled packs) is surfaced, not silent

Refs #1408, #1404.

[coderabbitai]

🔗 Related PRs

#1404 - Merge comfy-builder into main [open]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!