Reopening VT file after saving with bundled subworkflow won't offer subworkflow upgrade

[remram44]

The bundled subworkflow is used, and the module is up to date with the bundled subworkflow, so the upgrade is not offered.

From #725 (comment)

[rexissimus]

If this refers to upgrading to the latest local subworkflow version, this should be fixed by 9e0891a.

[remram44]

So it will just select any subworkflow with the same name, if the version number is higher?

[rexissimus]

Local subworkflows now registers old namespaces so that upgrades are detected. This only works if the local and bundled subworkflows have not deviated, like through a module upgrade. In this case there is no clear upgrade path. Is this what you are referring to?

[dakoop]

What happens when the local and bundled subworkflows have deviated and there is no clear upgrade path?

[rexissimus]

The upgrade is not offered because the bundled subworkflow namespace does not exist in the local subworkflow. I guess we could compare origin uuid:s, but it would be unclear which of them are newer.

Maybe we should just let users recreate the subworkflow at this point? Since we don't name subworkflow versions it is difficult to tell the current state anyway.

[dakoop]

I agree with the decision not to try to offer an upgrade because this would be an ambiguous situation. Offering an option to "merge" the two may be possible, but this should be distinguished from the normal "update".

[remram44]

I'm not sure I understand, the local subworkflow xml files store the namespaces?

Is this all documented somewhere in the code? These namespaces are not obvious at all.

[rexissimus]

Unfortunately, the best documentation is in relevant commit messages like this one: 85b50d9

Basically, every time we save a subworkflow a new namespace is generated. Old namespaces are still stored. Old namespaces are loaded as hidden descriptors. The upgrade code checks for a matching namespace and then checks if the version number is newer. Then an upgrade can be performed.

[remram44]

Fixing this is possible by turning the __abstraction_uuid__ annotations into action-annotations, so that the namespace UUID identified a specific version in the specific workflow. However this is a breaking change that will need an upgrade path, and then another upgrade for UUID identifiers (#1091); I say let's fix it once in #1091.