Hi everyone!
Prefect 2.7.2 is here 
This release extends the recently added pause/resume feature with rescheduling of paused flow runs.
- You can now pass the
reschedule=True argument to the pause_flow_run utility to gracefully stop the infrastructure process and put the flow run back into a Scheduled state.
- This way, you can free up the infrastructure resources instead of keeping the original flow run process running while waiting for approval.
Note that: this kind of rescheduling pauses works only with flow runs created from deployments and requires results persistence using either the persist_result=True option on the flow decorator, or by setting it globally using the following setting:
prefect config set PREFECT_RESULTS_PERSIST_BY_DEFAULT='True'
You can now also manually pause a flow run in progress using the new Pause button directly from the flow run UI page:
Resuming a run can also be performed from the UI or code:
from prefect import resume_flow_run, pause_flow_run
id_ = "pasy_your_flow_run_uuid_here"
pause_flow_run(id_, timeout=4200, reschedule=True)
# once you're ready to resume (you can do it from the UI, too):
resume_flow_run(id_)
Other enhancements and improvements in this release:
-
Two new Prefect Collections: prefect-kubernetes and prefect-bitbucket
-
Task Run Concurrency UI page now includes details and shows active task runs currently using allocated concurrency slots
-
New Opsgenie notifications block - kudos to Julien Lutran for contributing!
-
Fixes to imports and their performance
-
New SecretDict block field that allows to obfuscate nested values in a dictionary on blocks such as GcpCredentials or FugueEngine
-
If you have a flow call (e.g. myflow()) in your flow script, not protected by an if __name__ == "__main__: block, any run from that deployment will now work without giving you a warning about that unprotected call
-
Several documentation improvements incl. new with_options usage examples, recipe and tutorial references, Automations docs, and more!
For all enhancements and fixes, check the release notes - it even includes a Marvin joke. 
Happy engineering!
1 Like
How does a paused flow with reschedule=True surface in the UI? Does it persist with the same flow run name and ID, just a flow state change to scheduled?
Within the docs the pause always seems to be called from within the flow. I assume we can still call a pause from within a task as well? What is the resulting task state when that happens?
This is very different from 1.0 where raise PAUSE would pause a task and the resulting task state would be paused but the flow run would remain in a Running state. Could it be possible to add a meta state of Scheduled as ‘Paused’? There should be a way to know what flows you have that started and are now paused, if they are just lumped in with all of our future scheduled flows then how are we to know what our open items are?
We have an implementation in 1.0 across 100+ flows where we have a batch process occurring outside of Prefect that will unpause a Prefect flow when complete. It looks for a running flow run of a certain flow id and then checks if there is a certain task within that flow run in a paused state. This seems like a more straight forward and informative than what is being created in 2.0. In 2.0 I guess I would have to go through all flow runs of a flow that are in a Scheduled state and identify which, if any, have tasks that are in a success state (will they even be? Or will they be pending and then use stored results on resume?).
Without a paused state it seems difficult to discover flows that were paused. All in this is just a pretty significant change for those using raise Pause in 1.0.
the run is marked as Paused but the infrastructure process terminates. Once you resume, it goes again into Scheduled state and new infra process is spun up but it’s still the same flow run
yes, 100%
depends on where you call it - I recommend you try that out and once you got a couple of examples, you’ll get a feeling on his this works. Essentially if you get to a final state, then result is persisted, otherwise the task or flow run resumes from the beginning or from the last result it can retrieve
this is the default behavior here as well aka reschedule=False
Ok… thank you for the clarification. This sounds more in line with what I was expecting. Happy to see that the flow run will be marked as paused and then only to scheduled after resuming… that wasn’t entirely clear at first. I think I will have to see it in action to fully comprehend, but it sounds closer to the 1.0 behavior than I first thought. Thanks for the speedy response!
1 Like
