Polish Workflow Refactoring API

[jmchilton]

Post merge of #10988 which introduced this API.

• Add new refactoring steps:
  • {action: 'upgrade_subworkflow', step <StepReference>} Implement edit & upgrade subworkflow buttons in workflow editor. #11032
  • {action: 'upgrade_tool', step <StepReference>} Implement edit & upgrade subworkflow buttons in workflow editor. #11032
  • {action: 'fill_step_defaults', step: <StepReference>} Implement edit & upgrade subworkflow buttons in workflow editor. #11032
  • {action: 'fill_defaults'} Implement edit & upgrade subworkflow buttons in workflow editor. #11032
  • {action: 'update_output_label'} Implement edit & upgrade subworkflow buttons in workflow editor. #11032 (not important, but helped with testing)
  • {action: 'restore_workflow_version'}
• Rework response to include a structured message for each input action. So things like disconnected inputs/outputs during subworkflow upgrades of tool state upgrades can be presented to the user and tracked. Implement edit & upgrade subworkflow buttons in workflow editor. #11032
• In dry_run=true, capture the messages and do some extra checking that could predict database problems (specifically, I'm sure we could catch label problems at this step and we probably don't.)) Implement edit & upgrade subworkflow buttons in workflow editor. #11032
• dry_run=true should return the effective new state, so the UI can do stuff like upgrade_subworkflow or restore_workflow_version, render the results and display the messages but still require a "Save" before the new version is committed. Implement edit & upgrade subworkflow buttons in workflow editor. #11032
• Store typed and structured actions and messages in the database along with the new workflow version created.
• Rework hasChanges tracking in Index.vue to track structured list of changes, use the refactoring API when possible.
• Eventually use refactoring API for all UI interactions that touch the Workflow object (something like editing the tags might be fine with the old API). (This would essentially implement Diff-based Workflow Updates #9166).

[mvdbeek]

Do you think it'd be possible to also extend this to check for invalid references ? E.g referring to #{some_output}, when some_output is not a tool output?

[jmchilton]

Do you think it'd be possible to also extend this to check for invalid references ? E.g referring to #{some_output}, when some_output is not a tool output?

Tracked that on #10989 - seems like a really good idea. I think the client has everything that would be needed - I think recovering the logic for how we reference nested inputs on the client would be the hardest part?

[simonbray]

What about a UpgradeWorkflow action to update all tools and subworkflows automatically? I think that would be useful both through the API and the UI. Currently, as far as I understand, you have to loop through all workflow steps with UpgradeTool and UpgradeSubworkflow actions.

[jmchilton]

UpgradeWorkflow seems like a solid idea to me! I don't know if I'll have time to work on it in Q1 but it is a good thing to keep in mind. I think the hardest part would simply be fixing up the tool upgrade action to the point that we would want to expose it to users. The subworkflow upgrade logic for dropping connections and workflow outputs would need to be refactored to be reused when apply the upgrade tool action. After that was working, I think it would simply be a matter of looping over the workflow and executing these steps when needed.

[simonbray]

Maybe I could work on this?

the hardest part would simply be fixing up the tool upgrade action to the point that we would want to expose it to users

Can you elaborate? I guess you are referring to this comment here:

galaxy/lib/galaxy/workflow/refactor/execute.py

Line 484 in ca84356

# TODO: recalculate connections and record messages...

[jmchilton]

Yeah - that comment. There is a bunch of code in the prior method that works on subworkflow modules that can be refactored and reused for tools.