[Bug]: Group Nodes Broken

[PrometheusDante]

Frontend Version

0.16.7

Expected Behavior

What it looks like on frontend 0.15.9, while executing perfectly well.

Actual Behavior

What it looks like on frontend 0.16.7, unable to execute at all.

Steps to Reproduce

Load a workflow with group nodes and switch workflow tabs back and forth to have all hidden widgets appear and be misconnected internally.

Debug Logs

-

Browser Logs

Setting JSON

What browsers do you use to access the UI ?

Mozilla Firefox

Other Information

As of now my workflows can't be executed on frontend version 0.16.x
And there is an infinite list of link validation errors on load up, which I can't interact with.

┆Issue is synchronized with this Notion page by Unito

[huchenlei]

Group node won't be maintained. We will start the deprecation process in 1.17. Please stay in 1.15 and try convert group node to normal nodes.

[diodiogod]

Group node won't be maintained. We will start the deprecation process in 1.17. Please stay in 1.15 and try convert group node to normal nodes.

Why? I'm not a dev, and I'm in no position of criticizing you guys for your decisions, but seams like a setback... I used groups quite a lot. I'm just curious.

[PrometheusDante]

I agree, this appears like a downgrade. Is the subgraph feature close to being complete? And why not wait for it to properly replace the group node feature to have a smooth transition?

[webfiltered]

Just in case there is some confusion on terminology, deprecating a feature does not involve immediate removal. It is a method to convey that a feature is not/no longer the preferred way to do something, and will be removed at some point.

If you are experiencing issues with group nodes in the latest frontend, you may continue using an earlier frontend version until it is resolved (well, replaced).

[PrometheusDante]

Thank you for joining @webfiltered
The deprecation process does make sense, if there is an alternative way to do the same thing. For a while now more and more changes were introduced that affected group node handling detrimentally, but I managed to build my way around those, for instance by converting integer and float values to the number type and using combo values for strings to bypass the issue of forced inputs being at the bottom of a group node.

But in this instance I have no way of getting around the changes, which makes the subgraph feature's implementation more and more important going forward.

As of now an update to the new frontend versions would entail a downgrade to all my published workflows. Going back to normal nodes as @huchenlei suggests would not allow retaining the complexity and quality of group nodes.
Many users are intimidated by ComfyUI in general and any workflow with more than 20 nodes is already considered "advanced" by some.

---

To visualize the impact:

An example of my latest Flux workflow:

Flux Advanced v23

which has 180 nodes visible.

And this is how it looks deconstructed:

Flux Advanced v23 Deconstructed

which has 1122 nodes exposed.

---

Needless to say that would be a bit more clunky to work with and likely not look very accessible to new users either.
Of course some nodes could be gotten rid of as their purpose was formatting the group node's appearance, but that would hardly make a dent.

[marduk191]

Another reason to never use comfy in a production environment. Constant breakage and deprecation of features already deployed en mass.

[diodiogod]

Just in case there is some confusion on terminology, deprecating a feature does not involve immediate removal. It is a method to convey that a feature is not/no longer the preferred way to do something, and will be removed at some point.

If you are experiencing issues with group nodes in the latest frontend, you may continue using an earlier frontend version until it is resolved (well, replaced).

Thanks for the explanation! It makes more sense now.

[set-soft]

Group node won't be maintained. We will start the deprecation process in 1.17. Please stay in 1.15 and try convert group node to normal nodes.

IMHO this should be done after subgraphs are deployed and working. So you can say to people: we have something better, go ahead and migrate.

Oh! BTW, if frontend 1.16+ is so incompatible, why new ComfyUI depends of it? IMHO another very bad decision, if you want freedom to break every single interesting workflow out there then at least provide compatibility by installing 1.15 in current ComfyUI. Yes I know it takes work, I maintain software, but this is part of the game.