[GH-ISSUE #3126] "Fix node (recreate)" throws on frontend 1.47+ (string node ids), leaves duplicate node on canvas #1103

New issue

Open

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

bsakaguchi commented

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

Owner

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

What happens

Right-clicking a node with a connected input and choosing "Fix node (recreate)" throws instead of finishing, and the graph ends up with two copies of the node: the original (still wired) and an unconnected replacement stacked on top of it.

Console:

TypeError: t.findInputSlot is not a function
  at LGraphNode.connect
  at node_info_copy   (node_fixer.js)
  at callback         (node_fixer.js)

Root cause

In js/node_fixer.js, node_info_copy() reconnects inputs like this:

let src_node = app.graph.getNodeById(link.origin_id);
src_node.connect(link.origin_slot, dest.id, input.name);

dest.id is passed instead of dest itself. Node ids are strings on current frontend versions, and LGraphNode.connect() only resolves its second argument to a node when it's a number — a string id sails past that resolution and connect() ends up calling findInputSlot on the id string, which throws.

The callback also creates the replacement node and copies data into it before removing the original:

let new_node = LiteGraph.createNode(nodeType.comfyClass);
app.canvas.graph.add(new_node, false);
node_info_copy(this, new_node, true);
app.canvas.graph.remove(this);

Since the exception happens inside node_info_copy, graph.remove(this) on the next line never runs, so the original node is never cleaned up. That's the duplicate.

Not specific to any one custom node pack — this happens to any node with a connected input.

Suggested fix

In node_info_copy, pass dest (the node object) to connect(), not dest.id. Same for the output-side loop below it, which already does this correctly (dest.connect(parseInt(i), target_node, link.target_slot) — target_node is an object there, not an id).
Move app.canvas.graph.remove(this) to before the reconnect calls (or at least before the input-copy loop), so a failure partway through doesn't leave both nodes on the canvas. An input only holds one link, so reconnecting before removing the old node fights the link still attached to it anyway.

To reproduce

Add any node with a widget/input, connect something into it.
Right-click → "Fix node (recreate)".
Console throws findInputSlot is not a function; two copies of the node are left on the canvas, only one still wired.

Frontend version: 1.47.11. Related but not the same bug: #380 (stale link objects after recreate, filed against an older frontend) and the now-closed #1872 (wrong link position after recreate, frontend 1.19.9) — neither describes this specific string-id/exception path.

Happy to open a PR with the two-line fix above if that's useful.

Originally created by @EnragedAntelope on GitHub (Aug 4, 2026). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/3126 **What happens** Right-clicking a node with a connected input and choosing "Fix node (recreate)" throws instead of finishing, and the graph ends up with two copies of the node: the original (still wired) and an unconnected replacement stacked on top of it. Console: ``` TypeError: t.findInputSlot is not a function at LGraphNode.connect at node_info_copy (node_fixer.js) at callback (node_fixer.js) ``` **Root cause** In `js/node_fixer.js`, `node_info_copy()` reconnects inputs like this: ```js let src_node = app.graph.getNodeById(link.origin_id); src_node.connect(link.origin_slot, dest.id, input.name); ``` `dest.id` is passed instead of `dest` itself. Node ids are strings on current frontend versions, and `LGraphNode.connect()` only resolves its second argument to a node when it's a number — a string id sails past that resolution and `connect()` ends up calling `findInputSlot` on the id string, which throws. The callback also creates the replacement node and copies data into it *before* removing the original: ```js let new_node = LiteGraph.createNode(nodeType.comfyClass); app.canvas.graph.add(new_node, false); node_info_copy(this, new_node, true); app.canvas.graph.remove(this); ``` Since the exception happens inside `node_info_copy`, `graph.remove(this)` on the next line never runs, so the original node is never cleaned up. That's the duplicate. Not specific to any one custom node pack — this happens to any node with a connected input. **Suggested fix** - In `node_info_copy`, pass `dest` (the node object) to `connect()`, not `dest.id`. Same for the output-side loop below it, which already does this correctly (`dest.connect(parseInt(i), target_node, link.target_slot)` — target_node is an object there, not an id). - Move `app.canvas.graph.remove(this)` to *before* the reconnect calls (or at least before the input-copy loop), so a failure partway through doesn't leave both nodes on the canvas. An input only holds one link, so reconnecting before removing the old node fights the link still attached to it anyway. **To reproduce** 1. Add any node with a widget/input, connect something into it. 2. Right-click → "Fix node (recreate)". 3. Console throws `findInputSlot is not a function`; two copies of the node are left on the canvas, only one still wired. Frontend version: 1.47.11. Related but not the same bug: #380 (stale link objects after recreate, filed against an older frontend) and the now-closed #1872 (wrong link *position* after recreate, frontend 1.19.9) — neither describes this specific string-id/exception path. Happy to open a PR with the two-line fix above if that's useful.

bsakaguchi referenced this issue

2026-10-28 21:03:34 +00:00

[PR #1103] [MERGED] custom-node-list update #1713