In rare cases, interactions with Components on KNIME Hub can cause loss of files in your local workspace. In order to avoid this problem from occurring, we have restricted Component downloading from the Community Hub for the affected versions of KNIME Analytics Platform.
We highly recommend updating Analytics Platform 4.7.0 - 4.7.3 to 4.7.4 (available now) as soon as possible and 5.0.0 to 5.0.1 (which will be available on Monday).
If you are accessing an in-house installation of KNIME Business Hub (not KNIME Server!) and are still using one of the affected Analytics Platforms, refrain from opening Components on that Hub until you have upgraded as well.
We will provide more information and a more thorough technical explanation on Monday but wanted to alert our user base as soon as possible and also explain why access to Components is limited on the Community Hub and why we heavily encourage an update to 4.7.4 / 5.0.1.
Could this cause the total disappearance of a workflow group? (ie a folder and its contents from within the workspace) I had that happen to me about a week ago when I was uploading and subsequently retrieving a component from the hub. KNIME momentarily showed the splash screen and I couldn’t work out what had happened but a few minutes later I realised one of my workflow groups had vanished. It had totally disappeared from my workspace. A search of my entire hard drive didn’t find any trace of it. I ultimately recovered the group folder from a backup I had on another drive. Seems too much of a coincidence for this to not be related, but it would sure put my mind at rest to know it was a bug and not something weird that I’d managed to do.
Thanks for letting us know. I guess, you can put your mind at rest, this sounds related - make sure to upgrade to 4.7.4. On Monday we’ll provide more explanations and technical details on the bug.
I had the same thing happen in v5 pre-view (dual install used for forum helping) which wiped out the folder that held most of my forum help workflows, and I lost a workflow group around the same time in 4.7.1 in my working version which is synched on Dropbox and was recovered through their backup / recovery.
It basically helped me clean up a bunch of unused clutter in the end and I recovered in a few minutes, so I just kept on working and didn’t post on the forum. Next time I will report back on quirks like that for the greater good.
Hello @iCFO and @takbb (and all others).
What you are describing could be caused by that problem (i.e. until last week Friday, which is when we disabled that piece of functionality for the affected KNIME versions).
So in essence, a folder from your local KNIME workspace was deleted if you temporarily open a component from KNIME (Community) Hub by, e.g. double-clicking it in the KNIME Explorer, and then saving that component via Save-As to a local folder. It only happens to component editors (not workflows, nor components contained in workflows), which got saved to your local workspace. KNIME then falsely assumed that the component was still in a temporary state when the editor was closed and deleted the folder it’s contained in.
As @christian.birkhold described above, it only affected versions 4.7.0 - 4.7.3 and the 5.0.0 preview (for which hub connectivity is now limited and users need to update their clients).
I’m glad you had a backup of the respective folders and could restore (and clean up) your workflows!
That does describe what I would have done about a week and a half ago when I suddenly lost a local workflow group containing my components.
Unusually that day I did open the component directly from hub to edit it before trying to save it back locally for testing the changes. Normally I drag the component from my public hub space to a local workflow then disconnect it to edit, but I remember that that day I did it “the quick way” … because I was in a hurry…
errors: Java Edit Variable Bundle “org.glassfish.javax.json” required by this snippet was not found.
I think it looks like very early version, because many packages are missing or errors occur. I had to revert to 4.7.5 because it’s unclear what errors I would encounter and because I had workflows to run. I will update when everything is normal in the version.
Since the structure of my workflows is large, I did not examine it in detail. I downgraded because I needed to get everything working. If I’m not mistaken it was related to selenium nodes and remembering the browser profile. I haven’t looked at the different ones.
But there is a big problem here, after all, like me and I’m sure many people have workflows that work with legacy packages. It was not very correct to update with the package removal process, which would affect an existing workflow, maybe hundreds. Maybe it will cause too much waste of time and work for an alternative arrangement.
There should have been an integrated solution for those who would be affected in more detail by thinking more broadly.
Now think about it for a minute I have 500 workflows working with this package and they are all affected I need to rearrange or update everything. I need to check that they are working correctly. And how would you feel if I said would you do it for me?
Please consider the issues inclusively while updating, it will create healthier and more consistent results for everyone.
org.glassfish.javax.json is an internal bundle that was never to be used as a public stable API. Especially in a Java Edit Variable node it also seems strange to work with JSON objects. The only bundles that you can safely rely on are KNIME bundles and this was the main motivation for offering that functionality in the first place (e.g. accessing data types from extensions).
I would first double-check whether you really need this bundle.
This change is also mentioned in the release notes.
The library to process Json documents has been updated to a the new namespace jakarta.json - 3rd party node extensions depending on it will need to be adjusted (currently causing compilation errors). Workflow users depending on the class names in, e.g. a Java Snippet node, might need to adjust their script (some fixing has been done but probably only fixes 80% of the use cases).
