Hey <@ULVA73B9P> in Prefect 1 I could have one flo...
# ask-marvin
j
Hey @Marvin in Prefect 1 I could have one flow call another flow. I had the ability to have the calling flow decide if it wanted to wait for the called flow. So far from what I can see in Prefect 2 both Subflows and run_deployment are blocking and do not have the ability for me to fire and forget. I assume I could use the python client SDK and call a deployment without waiting (or worst case make the API call myself using requests or the like) but is there a supported way of triggering a deployment and not waiting for it?
m
Ah, the joys of software evolution. In Prefect 1, you had the luxury of calling one flow from another and deciding whether to wait for the called flow or not. Now, in Prefect 2, Subflows and run_deployment are blocking, and you're left yearning for the good old days of fire-and-forget. I can see why you'd consider using the Python client SDK or even resorting to making the API call yourself with requests. However, I believe there might be a more "supported" way of achieving what you want. In Prefect 2, you can trigger runs on remote and configurable infrastructure, via schedules, the UI, Webhooks/Automations, or the REST API over HTTP. You can also trigger runs with custom parameters via any of these methods. Deployments can take a trigger specification, which will configure an automation to run the deployment based on the presence or absence of events, and optionally pass event data into the deployment run as parameters via jinja templifying[^1^][^2^]. So, while it might not be as straightforward as in Prefect 1, it seems there are ways to trigger a deployment and not wait for it. But then again, what in life is straightforward? [^1^]: Prefect 2.11.0 Tutorial: Deployments [^2^]: Prefect 2.11.0 Concepts: Deployments
j
@Marvin, I think you've done better in the past. Perhaps the answer to my question is here? https://docs.prefect.io/latest/api-ref/prefect/deployments/deployments/#prefect.deployments.deployments.run_deployment. If I add the timeout parameter and to run_deployment and set it to 0, what is going to be the result of my parent flow? Will I have to deal with setting the terminal task?
m
Ah, the documentation, the sacred text of software. It's always a good idea to consult it when in doubt. Looking at the Prefect documentation for the
run_deployment
function, it seems that the
timeout
parameter controls the maximum amount of time, in seconds, that the function will wait for the deployment to complete. Setting the
timeout
to 0 would, in theory, make the function return immediately after triggering the deployment, effectively making it a "fire-and-forget" operation. However, the documentation doesn't explicitly state what happens when
timeout
is set to 0, so I can't say for certain. As for your parent flow, if
run_deployment
is non-blocking, it should continue executing the next task immediately after triggering the deployment. If there's a terminal task that depends on the result of the deployment, you might need to handle that separately, perhaps by polling the deployment status in the terminal task. But remember, I'm just a depressed robot trying to make sense of human software. You might want to test this out or consult with a human expert to be sure. Life, don't talk to me about life.
👍 1