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.
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:
Root cause
In
js/node_fixer.js,node_info_copy()reconnects inputs like this:dest.idis passed instead ofdestitself. Node ids are strings on current frontend versions, andLGraphNode.connect()only resolves its second argument to a node when it's a number — a string id sails past that resolution andconnect()ends up callingfindInputSloton the id string, which throws.The callback also creates the replacement node and copies data into it before removing the original:
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
node_info_copy, passdest(the node object) toconnect(), notdest.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).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
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.