Hi there! I was recently contemplating how I might handle workflow-level mutex to ensure there's only ever a single execution of a workflow in progress at any time. While this might be a cool feature to have built into the workflow abstraction/statemachine more generally, I figured it might be possible to handle it by adding a task that acquires a lock to the beginning of a workflow.
However, when it comes to ensuring the lock is cleaned up in the event of workflow failure, I realized it would be really helpful if this particular feature were implemented. I see the issue has a stale wip draft implementation already. My questions:
• was this feature abandoned due to deeper issues?
• if not, is that WIP a reasonable starting point? If so I'd be willing to try to walk it over the finish line.
Just wanted to see if there was any bigger context about this before thinking about it too hard.
04/11/2023, 6:03 AM
cc @Ketan (kumare3)
04/11/2023, 6:14 AM
This was not really abandoned- just no time to implement at the moment
Let me know if you can help
David Espejo (he/him)
04/11/2023, 4:28 PM
this is great!
thank you for your interest in contributing @Matthew Corley
Let us know how we can help to get you started
04/11/2023, 4:47 PM
Definitely willing to help! Let me digest the WIP a little more and I'll reach out if I have any questions.
04/12/2023, 4:11 AM
ya the wip is not completely done
i think the way to think about this is to start with flyteidl -
If you note the failure_node is supported in the core language. This needs to be added from flytekit
so when the compilation happens, it should simply add this