Hi Michael,
Unfortunately this is a known issue. When you undo/redo changes in the workflow application, the amount of memory that the ppwfg.exe process uses increases. If the workflow application is never closed, this amount will continue to increase until it reaches a threshhold of around 1.5Gb, at which point it will corrupt your active config file. This is most likely what caused the error message.
To try and resolve this:
Make sure your Undo/Redo option is turned ON (in case you turned it off earlier)
Delete one of your processes. Pick the smallest possible one that you know you can recreate easily if anything goes wrong.
Try saving the config and check whether the file was saved properly
Before doing anything else, try Undo’ing the last action (when you deleted your process) to see if the application is able to recover it.
If the Undo method worked, it means you should be able to perform the above procedure several times until the save operation is successful. You may end up losing a few processes but it’s better than losing everything.
Note: If you have autosave enable in preferences, it’s possible you’ll have a config file with the extension “._as” in your PlanetPress Watch folder. If you have that file, you can change the extension to “.ol-workflow” and then load that configuration.
I can’t believe this issue hasn’t been fixed yet, we have lost so may hours of work with the out of memory issue and has been going for for so many years
@Phil Tagged phill in the message as he is our Workflow guru
I have the same problem at a customer of us. But this is not related to the undo option.
They have a big workflow config with a lot of processes. When changing 1 or 2 plug-ins (e.g setting variables) they get directly a out of memory. Also when debugging the flow with no changes made this problem occurs after a few minutes.
I have withness this issue during the day and i have seen it more than 10 times in a few hours while working in de config. This customer is still working on 2022.2, seeing this message upgrading is not the solution.
The only “known issue” we have is tied directly to the Undo/Redo functionality (which, unfortunately, is still not completely fixed as it relies on an external library over which we have little control).
I have seen configs that are close to having the maximum number of processes (512) and they can be edited without running into memory issues (although, admittedly, the GUI can feel sluggish at times).
So my first question would be: are you able to work with that customer’s config on a different machine? What are their hardware specs?
If the error is reproducible on more other machines as well, I think you’d better reach out to our Support team so they can take a look at the config and try to figure out how to fix the issue.