Workflow changes cannot be saved (with cause)

[flemur]

Custom Node Testing

• I have tried disabling custom nodes and the issue persists (see how to disable custom nodes if you need help)

Expected Behavior

After making changes to a workflow and clicking save, the changes should be saved. They are not, when a specific trigger happens. This is reproducible.

Actual Behavior

Prerequisites:
Create a workflow, using get/set nodes. This happens with EVERY plugin that uses get/set nodes. It is not plugin-specific. If I don't use get/set nodes, it doesn't happen. It didn't used to happen. I've tested it on v0.8.2+ and on three browsers, as well as on RunningHub. This happens with both EasyUse and KJnodes. Because the bug appeared at the same time with both, this appears to be something that changed in Comfy, not their plugins. Disabling all plugins gets rid of get/set nodes, so yes, it prevents the bug...by removing the capability entirely. :)

Causing the bug:
Once you're using get/set nodes that are connected to a variety of things, delete something that they're connected to. As an example, I have get_image1 and get_image2 connected to an image compare node. If I delete the image compare, the whole workflow breaks. I can no longer save. If I try to save, it says it saves, the file modification date changes, but the file actually reverts to before I deleted the compare. This can result in hours of lost changes, when this bug triggers unknowingly. All changes FOREVER are lost, until you reload to before the bug happened. This doesn't happen 100% of the time, but very close to it. It seems to happen more when there are a greater quantity of get/set nodes. It's also much more likely to trigger on nodes that have more than one get node attached to them (like the compare). Switches are another good example, as they can have lots of get nodes attached.

The fix (Must be done in this order!):
If you have a workflow doing this, you can gradually fix it by reverting to the working version, then removing the connections to get-nodes, before deleting the connected node. Alternatively, you can delete all get nodes from the part you wish to delete, but they must be removed (and the wf saved) before you can delete things they were connected to.

In my image compare example above, if you remove both connections to get nodes, then save, then remove the compare node, it saves fine. The problem is that you don't know when this bug has occurred. At any time, it might happen and ALL saves break, until you revert and lose all the changes. The fix is only useful if you know it's already happening. Once the bug happens, no amount of saving or link-adjustments will fix it, until you reload.

Side-notes:
Even turning on the option for detecting broken workflows doesn't detect this.
The easiest way to spot if this is happening...if you select a group of nodes and try to delete it, but only SOME delete...it's bugged. In my workflow, I first noticed this when removing a second set of samplers. I selected the group, hit delete, and PART of the group disappeared. The workflow was bugged. If I reverted, disconnected everything (which is very time consuming), it saved fine. Often, if you select a large group of nodes that contain a get node, ONLY the get node will get deleted, which is an indicator it's broken.

Steps to Reproduce

1. Create workflow with get/set nodes, preferably connected to things like image compare
2. Save the workflow and confirm it's working
3. Delete the image compare, without removing the links to it from the get nodes
4. Save the workflow and reload
5. All the changes are reverted, even though the file supposedly saved fine

Debug Logs

Nothing is logged during a save of a workflow. Unable to provide any useful logs. There are no errors generated.

Other

No response