Hey P team, a question about dask interaction. We are looking for best practices for interrupting and then restarting a flow. Our use case is that we need to sever all database connections during a database migration. We would like to avoid restarting the flow from the beginning, but we are fine with re-starting any running tasks from the beginning (in fact I don’t think we have a choice there). We are thinking of the following steps: • pause all running tasks using graphql API • scale down dask workers to 0 (we run in fargate) • scale up dask workers after the migration • unpause the tasks Would love to hear any thoughts. Thanks! 🙏

Hey Jeff - based on what you describe, here’s what I’d recommend: - “cancel” the Flow using the new cancel button in the UI (assuming you are running on a newer version of Core) - once the Flow is fully cancelled, you’ll have a bunch of task runs in a “Cancelled” state - you might need to use the GraphQL API to set all “Cancelled” task runs into a “Pending” state - finally, Mark your flow run as “Scheduled” and it will get picked up and executed from the pending task run states We could probably work on making this experience more intuitive so you don’t have to jump around so much

Thanks for getting back so quickly @Chris White! At least for now I will go with the first option, because we don’t want to hold up a deploy to wait for a potentially long running task to complete. BTW we will do this all via the graphql API because we want the whole thing to run without human intervention as part of the deployment process.