<@ULVA73B9P> I have a flow with a number of tasks ...
# ask-marvin
a
@Marvin I have a flow with a number of tasks that sends a notification on complete/failed states; I would like to add a subflow that runs other things on the side (think analytics that can be accessed later) and taht does not interfere with the complete/failed notifications; what is the best way to structure something like that?
n
not sure why marvin ghosted you here. can you explain what you mean by
does not interfere with the complete/failed notifications
?
😂 1
a
if the sideflow fails or lags for whatever reason, I don’t want it to change/delay the status of the whole flow
if the sideflow fails or is taking too long, main flow should be still marked as complete
n
i think there's a couple ways you could approach this, but the most direct one to me is to create a separate deployment for the sidecar flow, and just
run_deployment(..., timeout=0)
that from your main flow when needed (timeout=0 means don't wait)
a
would this submit the sidecar as a whole new flow? would I be able to view it on the dag of the flow that triggers it?
n
yes
a
is there a way for the subflow to be part of the existing flow? I am using k8s and would like to limit how many pods im spinnning up
n
well, that's the behavior if you just call the flow-decorated python function from your parent flow, but you had said > I don’t want it to change/delay the status of the whole flow
a
yea… is there another way I can link them in prefect UI?
i.e. how can I know flow1 triggered sidecar1 without going into the db
n
i guess im not sure what you mean by sidecar then. IME "sidecar" is another container in the same pod so you want a subflow that's running in the same process as the parent flow, linked as a subflow in the UI, but doesn't influence the execution of the parent?
a
yup that’s exactly right
n
something feels strange about this to me. what if the "background" flow takes longer than the parent? should it keep the pod alive? I would think you might want to serve a couple tasks / flows in a long-lived container / pod and trigger runs of those as needed from your dynamically dispatched parent flows
a
background flow is not going to take longer
the sidecar is testing the next level flow which in general is faster
g
@Nate Is it possible to link 2 or more flow_runs with a parent or sibling type relationship, in the ui but have them be separate infra?
ie I create parent flow_run, then create child/sibling that is connected int he ui, but would run in different containers?
Another option could be can you create a shell parent flow with no infra and connect different child flow_runs