Change submit to cancel and block any launch button in case workflow is already running

[harshit-soora]

Related to Epic #4338

• Added a workflow_state in metadata, that switch between running and completed
• Support for cancel button in workflow that will STOP all the running jobs
• Blocked all Launch button when a workflow is running. Only way to submit another workflow is cancelling the current or will reset the buttons when it is completed.
• Job Hash was not saved in the backend upon retuning from the submit function. Fixed that.

[Bubballoo3]

I am not sure that limiting users to a single workflow run at a time is a good idea. I see a key use case of workflows as allowing people to submit very long jobs with several dependencies and then allow them to run for several hours. If you want to run several similar workflows at once (with different parameters), you could either make a duplicate workflow with duplicate launchers or edit a launcher and run the same one again, and I don't know why we would take away that option from people.

For the cancel button, you can already cancel by stopping any jobs that are currently running. While the cancel button could be useful for large workflows, I doubt many people will be canceling before seeing if the run is successful or not.

That is my first reaction, that this is kind of nice but not necessary, but open to hear your thoughts on those points.

[harshit-soora]

Now that I think of this, it is a strong point. May be we should allow submits even when one workflow is running. But, then Launch call should be blocked when a workflow is running. Also Launch call should be blocked when a subset of workflow (ie, induced by Launch itself) is running.

Since we don't have a way of separating two workflow launch as of today, right now best for user should be make a copy of existing workflow and use that if he/she wan't to run another instance in parallel. But stopping a user to do accidental subset launch and relaunch is essential.

Also in double launch right now, user will have no intuitive way to figure out what is running and what has failed (based upon UI). So, in my opinion this should be a great addition.

[Bubballoo3]

Also Launch call should be blocked when a subset of workflow (ie, induced by Launch itself) is running

I think I am ok with this part given the confusion that could generate and the simplicity of the fix. I am a bit wary of adding so much so late in the game, since we could have to re-cut release candidates if we find bugs next week. So a more limited scope could be nice.

Also in double launch right now, user will have no intuitive way to figure out what is running and what has failed

I don't think this is such a bad thing. The UI progress feature is an amazing tool for developing workflows, but once a workflow is developed and in use I think people will care much less what happens as it runs. If there is a 99% chance everything is successful then you wouldn't sit and watch every time, but if it fails you can always run it again 'supervised' to see exactly what is going wrong.

Once again, my main concern is that I am wary of adding much complexity at this stage, especially when a bug in that functionality could disable essential features of the workflow. So I am much more comfortable disabling the partial workflows (nonessential) instead of the submit button.

[harshit-soora]

my main concern is that I am wary of adding much complexity at this stage

I thought 12th Dec was the cutoff and everything since has been just going into master and will be picked in next release. Sure we can keep this on hold and add once v4.1 is out.

Plus I and Prof. Sussman have some view on Phase 2 of workflow, I will create another epic with details and we can discuss more there. May be I will move this PR under that.

[Bubballoo3]

Ok then yeah let's hold on this until 4.1 is finished. Release candidates haven't been cut yet, so everything merged so far will be in 4.1, just so you know.