Reroute nodes keep disconnecting about rgthree-comfy

[rgthree]

Hmm.. What is most helpful is if we can recreate it (as in, load it and it's working, do something, then we find it's broken).

I haven't noticed any breakages locally since the last code changes, so your workflow is the best change to catch it. If you could paste your curent workflow, the nodes that are generally affected, and what you generally do between it loading correctly and breaking, so I can try to see if we can recreate it.

[alessandroperilli]

Thanks. The workflow is here.

Where to look

The affected route nodes seem to be the following:

1. Red node carrying negative prompt here:

It disconnects 3 wires, 2 going up and 1 going down.

2. Grey node carrying negative prompt here:

It disconnects 1 wire going to the right.

If I find others, I'll update this specific comment.

How to reproduce

I can replicate the issue, just not consistently:

A. The nodes that are causing the problem are always these two. Which is odd because, as you can see, this new v4 is an almost complete rewrite of the workflow you previously saw. Yet, even in previous 3.x versions, I always had 2 nodes carrying some negative prompt information keep disconnecting.

Why always 2 nodes? Coincidence?
Why is has always something to do with the negative prompt? Coincidence, too?

Most certainly, but I wanted to point it out.

B. I discover these nodes disconnected after I have done one of the following actions + launched a run:

B1. Saved the workflow in PNG and reloaded the browser immediately after.
B2. Interrupted ComfyUI via CTRL+C on the console and restarted it.
B3. Fetched custom nodes updates, installed them, and then restarted ComfyUI.

However, I'm unable to systematically reproduce the problem. If I do B1 on repeat, the nodes don't disconnect. Same for the other actions. It's one of these 3 actions in combination with something else (a successful run? An interrupted run?).

Notice

1. Out of desperation, I simply deleted the two problematic nodes and recreated them. It's not a sustainable strategy, and I'm almost certain that I tried this in the past, but I might have altered the conditions now. I'll update this comment if I see another disconnect.

2. For reasons that I cannot understand, some of the most recent changes I have introduced in the workflow now cause a VERY LONG time to initialize the run. If you hit the Queue button and it seems like nothing is happening, it's just very, very slow. It will eventually start. I don't know what's happening but it's not related to the reroute disconnection problem. I had it before this new slow start issue.

I hope it helps. Happy to jump on a Discord chat to troubleshoot if our time zones make it viable.

[rgthree]

Cool. I'll see if I can take a look. The fact that they both come from "Negative Prompt Switch (Any)" makes me wonder if it's that node.. but their code doesn't look like it'd do something..

For the LONG time issue, there's some non-optimized recursion in ComfyUI itself. If you pull the latest from rgthree-node, it should fix it for you (I patch it until ComfyUI can get to it). Can see more here: comfyanonymous/ComfyUI#1502

[rgthree]

Alright, I think I found the issue; interestingly enough, it did have to do with that Negative Switch node and was a bit of a race condition when loading the workflow.

The "Too Long" version: The issue was that Reroute nodes ensure that they're connected to valid inputs and outputs at either end of a chain. If something happens and they aren't, they'll disconnect from the invalid slots (like, with a reroute node that has a STRING type coming to its input and its output is connected to another nodes STRING input, if an IMAGE type is then connected to replace its input, the Reroute node will disconnect from its existing output connected node, since it's no longer a STRING type). It does this check when its connections change.

This works generally for most nodes. the bug here was your workflow's connected ImpactSwitch node initializes without input type information, so if the Reroute checks its connections before that ImpactSwitch decides it's a STRING type, it would disconnect the reroute chains outputs.

I've fixed it for reroute nodes which won't do this type enforcement while a graph is being configured. Also, debounced the check too, which will help naturally anyway.

[alessandroperilli]

I appreciate the long explanation. More of these are welcome.

I'm testing the new version of your suite to see if I have any more disconnect and if the recursion problem is gone, too.

Thank you!