I have the same problem as described in Linked components couldn't update . I have many components and in one of them I get this error.
The component had many updates over time and initially it could be updated automatically until something unknown happened and the error occurred. I even expanded the component, recreated it, and shared it again, but still the error is still there.
I looked in the knime.log and noticed error messages, which I thought might trigger this component-update-error. I cannot share the workflow so I tried to make a simple workflow with those nodes mentioned in the errors hoping it could be reproduced. When I update this simple component I have these errors in the knime.log too, but now the update succeeds!?
So something goes wrong, but it is not shown in the knime.log!? Is there another place (log-file?) were to look what is done during an component-update? Is there a possibility to get closer to the real cause?
You responded in the above mentioned topic. Can you help me a bit further on my problem? I drag the component onto a workflow, I amend the configuration and use flow variables for some of the parameters. This result works fine on several different workflows until I have to amend the component. Once updated in one (shared with an absolute link) I cannot update the other workflows without this error. So I have to redo the drag/configure/use flow variables over again in all the other workflows.
I cannot share the workflow (or the component for that matter) so I tried to reproduce the error in another workflow. Though I get exactly the same warnings in the knime.log as in the original workflow, this dummy will update nicely.
Is there a way to get more details what really happens when an update of a component is executed?
The number entered via the Integer Configuration is added in de String Manipulation to make a name of a table to be read from the workflow data area. The table is created in step 1 and to be used in step 2. When executed in the correct sequence this works perfectly.
The real workflow contains more than 1 “step 1 / step 2” sets, so each set uses its own table-file.
What I did was change the top-version of the step-2 component, shared it and tried to update the bottom one. It gives the same warning in the knime.log as you can see in the first picture, but in this simplified workflow/components the update can be executed without problems.
So there must be something else in my real component which prevents a successful update … but what?
Thanks for the detailed explanation and for trying to reproduce it in a simplified example.
Since the simplified workflow updates correctly, it likely means something specific in the original component is causing the failure. Could you please share the relevant knime.log entries from when the update fails?
It would also help to enable DEBUG logging before reproducing the issue:
Copy the component to a new one (compnent*), changed one character in the name so I’m sure it is not related to the length a path-names (I’m running on Windows 11 and the maxlength of 255 positions is sometimes an issue).
Made a new workflow and dragged this component* twice on the workflow. I used again an Integer Widget to define one of the configuration parameters.
Changed the loglevel to DEBUG.
Disconnected one of them, changed something in the description.
Tried to share it to my components-folder, but this fails on a file template.knime which cannot be accessed. The complete folder with this component* is gone!
Sharing it again, which does not ask for overwriting the previous version anymore does work.
Now a manual update of the other component succeeds.
Changed the loglevel to WARN again.
Disconnected the updated one, changed again something in the description.
Shared this second update (confirm the overwrite). This fails again on the template.knime file which cannot be accessed.
Share it again (no overwrite required) and this time it succeeds again.
Now update the other one, which succeeds too.
As this all was without actually saving the workflow I tried something additional.
Make another change in the description and shared it again. This time is went okay the first time.
Save the workflow and close it.
Open the workflow again.
Now I get the reminder there are components to be updated. I choose to perform the update and guess what: success again.
I have no idea what is changed. I think I going to delete my shared component (from my Components-folder) and share it again. As if the fresh start removes any strange things collected over time.
The error regarding template.knime could be from a file-access conflict. When you overwrite a component template by sharing a copy over it, the original folder on your disk is replaced. If a background process (such as Windows Indexer or OneDrive/other cloud sync) happens to be accessing or “locking” the file at that exact moment, the replacement might fail.
Safer workflow: Another option is to open the original component template directly from the Explorer (Local Space or Hub) so it opens in its dedicated editor tab. Saving changes here edits the template in place rather than replacing the folder. This approach avoids the template.knime file-locking issues altogether.
A fresh start by deleting and re-sharing should clear the current issue, but using the direct edit method above will likely be more stable for your future updates.
I use this sequence of steps always when updating components and I have not seen this error on template.knime before. But the workaround is easy if it happens: share again
The suggestion to update a component directly might work if a component does not have any input. Often an update can only be made if there is data and/or flow variable available. Most nodes refuse to save changes if you specify a column of variable which is not yet available.
This makes developing a component which can deal with different circumstances sometimes challenging. And if something unexpected pops up, there is always the possibilty to update … Or I should say: there should be the possibility to update.
I think I know how to deal with this issue i the future. Thanks for your help (your questions forced me to test this better). I will mark your last reply as solution.
