Restoring of old version on share components corrupt


I am using a shared component and recently made changes to it. I’ve stored it with a version snapshot and wanted to restore this snapshot as the new version had errors.

The restore procedure works, but all my instances in the existing workflow are not updated to the restored version. The update checker does not realize the restored version as a new version.

I’ve I add the component newly back into the workflow I can see it is the restored content. It seems to be a bug.

Please fix that as quickly as possible.

As a workaround for all others:

  1. Restore the old version of the component
  2. open a sample workflow
  3. drag-n-drop a new instance of the component into the workflow
  4. unlink this new instance
  5. share again to the server
  6. perform updates in the workflows the component is used
  7. delete the sample workflow

Hi Marcel,

I have attempted to reproduce the issue you had mentioned but am not seeing the same results. Can you please let us know what version of Knime AP and Knime server you are working with? We will continue testing to see if we can reproduce the issue.


1 Like

Hi Marcel,

Just checking in to see if you could provide us with the additional information and if you are still experiencing this issue?

Hey everybody
I can confirm the issue of MarcelMeyer. Was/Is occuring with

  • KNIME Analytics Platform 4.1.3
  • KNIME Server
  • Also older KNIME Server version v4.9-something (I just upgraded server version in hope to fix this)


  • We have workflows with separate database connector components, which provide DB sessions to Querying components
  • I use snapshots to switch connector components between local and customer environment
    • Local usage of MySql
    • Customer usage of Oracle e.g.
  • Component contains one DB connector node; either MySQL (Snapshot 1 - older) or Oracle (Snapshot 2 - more recently snapshotted).
  • Before loading a workflow i restore whatever environment snapshot I need it for; following steps:
    1: Restore MySQL snapshot
    2: Load workflow from server
    3: Confirm component update dialog with yes
    4: Server updates connector to MySQL (working as intended)
  • but if I do:
    5: Replace snapshot now with Oracle one on server
    6: Click connector component in my workflow and select “update”
    7: Knime tells me “no updates available”
    8: If i drag the connector node from server repo into workflow, it has the Oracle connector in it
    9: The previously loaded one has the MySQL connector in it
    10: Both link to same server template and tell me “no update available”

Hope that problem description helps a bit :slightly_smiling_face:

Oh and one addition - we use the same workaround that Marcel suggested.

After a bit more testing this pattern seems to emerge:

If the (restored) component’s server snapshot date is OLDER than the version that is currently in used in a workflow, then the update seems to always end up with “no update available”.

If the component’s server snapshot date is after the version used in a workflow, then the update process triggers.

This is also in alignment with Marcel’s workaround, as - by re-publishing the older component to the server - the server date get’s reset.

I don’t know if this is intended behaviour, but at least for me this heavily devalues the snapshop functionality, because I can’t ensure that my restored snapshots get auto-updated in the actual workflows.

A feedback from you KNIME guys would be very welcome.

Hi Jan,

Thank you for the additional info, we are working on reproducing it and potentially filing a bug if necessary. I will keep you as up to date as I can.


Sure, feel free to reach out to me if you need any further details or a live demo :slight_smile:

Hello KNIME Team
Hope you have a good summer. Is there by any chance an update on this topic?

Hi Jan,

Apologies about the slow response. With our new release we have had a bit of influx of tickets come in. I will hopefully have an update for you today or tomorrow. This will likely be a ticket for our team to put a fix in as I’m not sure there is a better solution than your workaround at the moment.


Hi Jan,

I have put in the request with our dev team to take a look into this. I cannot give you a time table on when this issue will be addressed but please feel free to check out the updates page when a new release of Knime AP comes out. The ticket number to reference is AP-14878, and you can check our change log site here for the referenced ticket number to see when this will be addressed. You can also check other versions by changing the v41 to v42 or any other number of Knime AP.

1 Like


we just updated our server to 4.11 and experience even more issues. We needed to change some of our components due to new functionalities in KNIME. If we now store the new component version on the server, the old workflows are sometimes not updated as KNIME does not recognize that a newer version exists. Some components work, others not. I do not see a pattern anymore…You will need to look into this.

1 Like

Hi MarcelMeyer

I can actually confirm your experience, while unfortunately not being able to provide really helpful info at this point. We also have found some strange behaviour when it comes to updating components.

I have a feeling that this is somehow related to timestamps of components templates on the server or even on the local file system, compared to what is currently present in an actual workflow. Please note, this is pure guesstimating on my part.

I hope you guys can look into this soon.
Best, Jan

Hi @JanSteinwand and @MarcelMeyer

we validated what you did experience with this problem. The reason is that the update process of components checks if the linked component was created after the current version. Only than the component does get updated. Using snapshots for having two versions of a component and replacing the snapshot only, I have to admit, is a really brilliant idea! We did not have this in mind when we designed the component update procedure.

Changing this behavior now could potentially be undesired by other users, so we need to be careful not to break backward functionality.

We will keep working on this, to improve this situation.

Best wishes, Iris

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.