Can you do recursion with prefect flows, is there ...
# prefect-getting-started
t
Can you do recursion with prefect flows, is there any restrictions on that or deploying those flows?
n
i suspect it would technically work for flows, but not tasks. my main question would be why you’re reaching for recursion with a flow decorated function? i have had flows that call recursive functions, but have never needed the flow itself to be recursive
all that should matter as far as the deployment should be the entrypoint, which shouldn’t be different if the flow was recursive
t
Thanks Nate, good to know this is possible! So my situation is i'm calling an API, and that API fails transiently and unpredictably for certain cases, i wanted that API call and then loading of that data to be a flow (since it consists of multiple steps / tasks). I thought if making it recursive so that it would retry any failures repeatedly until i had all of the results back. I can't implement retries server side as i don't control that. The API only provides an async endpoint where i send POST requests, then receive a job id which i can subsequently use to retrieve the results with a GET request. So i can't tell jobs have failed until when i go to retrieve them with the GET requests (unlike if i were using a sync endpoint and could retry failures immediately). There may well be an obvious and simple solution i'm missing.
n
cant you set retries on the flow? retries will just rerun your flow upon failure client side
t
I guess the difficulty there would be i wouldn't know how to do the retries only on the data that failed? as 99.9k might succeed and 100 fail, and i'd only want to run the 100 through
n
i guess i’m not sure what you mean by “data that failed” but i would want to write my flow such that it would fail if what i care about fails, so i can set retries on the flow (or subflow) and it can selectively retry when the thing i care about fails
t
So by fail i mean: • My POST api request was successful • But my GET API request fails because the server failed silently on that job I can't make the whole async request journey a single task that gets retried because for 100's thousands of requests the latency overhead of a single task is too high. So i do the two steps of sending all the post requests, waiting, then retrieving all of the data with the GET requests.
I decided to ditch recursion and find another route :), thank you for the guidance here Nate!
👍 1
n
ah! sorry this dropped off my radar - sounds like you got it sorted?
t
Yes, all good now thank you!
👍 1