<@ULVA73B9P> I have a parent flow which runs a sub...
# ask-marvin
s
@Marvin I have a parent flow which runs a subflow. The subflow runs three tasks. When a task fails, I retry the parent flow from the UI. This triggers a new subflow run, rather than re-running the subflow which has the failed task. Is there a way to retry the parent flow without creating a new subflow run?
m
The specific details on how to retry a subflow in Prefect 2.x without creating a new subflow run or how a parent flow can be retried such that the same subflow execution is used are not directly addressed in the excerpts provided from the Prefect Discourse. Generally, subflows are treated as separate flow runs in Prefect 2.x, which might be why a new subflow run is created when retrying from the parent flow. However, there might be workarounds or advanced features within Prefect 2.x to handle this use case. I will search for any issues or discussions in the Prefect GitHub repository that might shed light on this topic. Let's look for any GitHub issues related to retrying subflows without creating new runs. From the GitHub search results, there isn't a direct issue or discussion that provides a clear solution to the problem you're experiencing with retrying subflows without creating new subflow runs. However, there is a related issue that mentions the handling of subflows and their states in the context of a parent flow: - Issue #10620 discusses a scenario where subflows fired with
run_deployment
cause the parent flow to be incorrectly marked as failed if they crash but then succeed upon infrastructure-level retry. This suggests that Prefect does observe subflow runs within the context of their parent flow, but there may be inconsistencies or unexpected behavior regarding state handling. The other issues don't seem to be particularly relevant to solving your retry challenge. Given the lack of specific guidance on retrying subflows without spawning new subflow runs, the correct approach to handle this case in Prefect 2.x likely depends on specific orchestration and state handling considerations that might need to be addressed through custom logic. You may consider reaching out to the Prefect community or the Prefect support for more tailored help on this matter. Alternatively, there may also be new features or updates that are not yet captured in the issues or discussions. You might want to review the latest Prefect documentation or even reach out to the Prefect community on Discourse for the most current and specific advice regarding your use case.
s
@Marvin is it possible to retry subflows from the UI?
m
According to the Prefect 2.0 release notes referenced in the excerpts, flow run retries (which would include retries for subflows) are configured similarly to task retries with the use of
retries
and
retry_delay_seconds
parameters. While the release notes provide guidance that flow retries are possible and configurable, they do not explicitly state that retries for subflows can be initiated directly from the Prefect UI. The typical process for retrying a flow involves setting retry parameters at the time the flow or task is defined, which then automatically handles retries according to your configuration. To retry subflows from the UI, you would typically look for the specific subflow run in the flow's run history and use the UI to retry it, similar to how you would retry a top-level flow. However, if the UI does not provide a straightforward option to retry subflows individually, this may be a limitation or an area that is subject to change as Prefect continues to evolve. For the most up-to-date and accurate details, you may want to consult the most recent Prefect documentation, or ask directly in the Prefect community forum or through their official support channels. If a UI feature has been recently added or if there are workarounds, the community or support team would be able to inform you about the current capabilities and best practices.