Run a flow in a subprocess.Note the result of the flow will only be accessible if the flow is configured to
persist its result.Args:
flow: The flow to run.
flow_run: The flow run object containing run metadata.
parameters: The parameters to use when invoking the flow.
wait_for: The futures to wait for before starting the flow.
context: A serialized context to hydrate before running the flow. If not provided,
the current context will be used. A serialized context should be provided if
this function is called in a separate memory space from the parent run (e.g.
in a subprocess or on another machine).
env: Additional environment variables to set in the subprocess.
Returns:
A multiprocessing.context.SpawnProcess representing the process that is running the flow.
Force this run through Cancelling -> Cancelled.Used when capture_sigterm has determined (via the cancellation
listener) that the SIGTERM was the runner asking for cancellation,
not an unrelated termination. Transitioning through Cancelling first
The same ownership rule also governs on_cancellation / on_crashed
hooks: if the engine owns cancellation/crash handling, it must
drive the Cancelling -> Cancelled transitions locally; if an
external runner owns them, the child should avoid duplicating
state history.
This method attempts to load an existing flow run for a subflow task
run, if appropriate.If the parent task run is in a final state, we return the existing
subflow run to avoid re-execution (unless the parent is being rerun
and the subflow did not complete, in which case a fresh run is
desired).If the parent task run is in a non-final state (e.g. still Running
after a process restart), we also look for an existing subflow run
to reattach to, preventing duplicate subflow runs from being created
under the same parent task run.If no existing flow run is found, or if the subflow should be rerun,
then no flow run is returned.
Force this run through Cancelling -> Cancelled.Async counterpart to FlowRunEngine.handle_cancellation. Shielded
from asyncio cancellation so engine-owned transitions always reach
the server.
This method attempts to load an existing flow run for a subflow task
run, if appropriate.If the parent task run is in a final state, we return the existing
subflow run to avoid re-execution (unless the parent is being rerun
and the subflow did not complete, in which case a fresh run is
desired).If the parent task run is in a non-final state (e.g. still Running
after a process restart), we also look for an existing subflow run
to reattach to, preventing duplicate subflow runs from being created
under the same parent task run.If no existing flow run is found, or if the subflow should be rerun,
then no flow run is returned.