@ancient-wolf-19325 what is the difference between reference workflow and external workflow

A reference workflow in Flyte is a pointer to a workflow that already exists on your Flyte installation. It allows you to invoke a workflow by specifying its project, domain, name, and version, but does not initiate a network call to Admin at definition time. The interface (inputs/outputs) must be provided and is checked at registration; reference workflows are typically used to compose or reuse workflows across projects or teams without duplicating code or logic. Example usage is via the

@reference_workflow

decorator in Python, which creates a local proxy for a remote workflow entity, but execution is only possible on the Flyte platform, not locally (flytekit/core/workflow.py, flytekit/core/reference_entity.py). An external workflow, on the other hand, refers to the execution of a workflow via a launch plan from within another workflow. This triggers a new, independent execution with its own execution ID and context, separate from the parent workflow. External workflows are useful for distributing workloads across clusters or for cases where you want the sub-workflow to have its own scheduling, resource, or parallelism constraints. In contrast, subworkflows (not external) execute within the same context as the parent workflow (subworkflows.md, tasks_workflows_and_launch_plans.md). Would you like a step-by-step breakdown or code examples? Sources: - subworkflows.md - flytekit/core/workflow.py - flytekit/core/reference_entity.py - tasks_workflows_and_launch_plans.md 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 give me an example of how to use reference workflow

To use a reference workflow in Flyte, decorate a Python function with @reference_workflow, specifying the project, domain, name, and version of the existing workflow. This creates a local proxy that can be invoked in new workflows, enabling reuse without duplicating code. The function signature must match the referenced workflow's interface (flytekit/core/workflow.py). Example:

from flytekit import reference_workflow, workflow

@reference_workflow(
    project="flytesnacks",
    domain="development",
    name="myproject.mymodule.my_workflow",
    version="v1"
)
def my_ref_wf(a: int) -> int:
    ...

@workflow
def parent_wf(x: int) -> int:
    return my_ref_wf(a=x)

Would you like more details or explanation of each part? Sources: - flytekit/core/workflow.py 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 When I try accessing reference workflow in a parent workflow I see the below error

Reference sub-workflows are currently unsupported. Use reference 
launch plans instead.

Reference workflows cannot be used as subworkflows within another workflow; Flyte does not support compiling reference workflows as sub-nodes. The error you see is expected—use a reference launch plan instead, which is supported for this use case (flytekit/tools/translator.py, fe87c0bc). Would you like a step-by-step example of using a reference launch plan in a parent workflow? Sources: - flytekit/tools/translator.py - fe87c0bc 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes please

Certainly! To use a reference launch plan in a parent workflow, you must first define the reference launch plan using the @reference_launch_plan decorator, specifying the project, domain, name, and version of the registered launch plan. Then, you can invoke this reference launch plan as a node in your parent workflow. This is supported and will trigger an external workflow execution (reference_launch_plans.md, reference_launch_plan.py). Step-by-step example: 1. Define the reference launch plan:

from flytekit import reference_launch_plan, workflow

@reference_launch_plan(
    project="flytesnacks",
    domain="development",
    name="data_types_and_io.file.normalize_csv_file",
    version="v1"
)
def normalize_csv_file(
    csv_url: str,
    column_names: list,
    columns_to_normalize: list,
    output_location: str,
) -> str:
    ...

2. Use the reference launch plan in a parent workflow:

@workflow
def parent_wf() -> str:
    return normalize_csv_file(
        csv_url="https://people.sc.fsu.edu/~jburkardt/data/csv/biostats.csv",
        column_names=["Name", "Sex", "Age", "Heights (in)", "Weight (lbs)"],
        columns_to_normalize=["Age"],
        output_location="",
    )

This setup will invoke the referenced launch plan as an external workflow execution within your parent workflow. Sources: - reference_launch_plans.md - reference_launch_plan.py 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 is there a way to fetch the active launch plan instead of using a specific version when creating a reference launch plan

No, when creating a reference launch plan with @reference_launch_plan, you must specify a version; there is no built-in way to automatically fetch and bind to the active launch plan version at definition time. The version argument is required (reference_launch_plans.md, ebf05c91). However, you can programmatically fetch the active launch plan using FlyteRemote at runtime, but not via the decorator. Would you like a code example of fetching the active launch plan programmatically? Sources: - reference_launch_plans.md - ebf05c91 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.