@ancient-wolf-19325 I'm trying to create a new version of a launchplan using

pyflyte register ... --version

. This works until i want to update the version of the

reference_workflow

that it points to. e.g., if v1 of my named launchplan points to a reference workflow that uses workflow v1, and then i want to register launchplan v2 that points to workflow v2, i get this error:

Request rejected by the API, due to Invalid input.
RPC Failed, with Status: StatusCode.INVALID_ARGUMENT
        Details: launch plan with different structure already exists:
                - /workflow_id/version: v1 -> v2

Is this intended behavior, or am i doing something wrong? i can easily get around the issue by giving my

LaunchPlan

a new name, but i don't want to do that every time i need to bump versions

This is intended behavior in Flyte: for a given launch plan name, you cannot register a new version that points to a different workflow version (i.e., the workflow_id/version field must not change between launch plan versions). If you want a launch plan to point to a new workflow version, you must use a new launch plan name. This restriction is enforced to ensure that a launch plan's structure remains consistent across versions—changing the underlying workflow is considered a structural change, not a version bump. See the error handling and test cases in errors_test.go and launch_plan_test.go. Would you like more detail on why this restriction exists or how to manage launch plan versioning in practice? Sources: - errors_test.go - launch_plan_test.go 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes, explain recommended best practices for managing and versioning launchplans that use

reference_workflow

It seems likely that the recommended best practice is to create a new launch plan name whenever you want to point to a new version of a reference workflow. This is because Flyte enforces that a launch plan's structure—including the workflow it references—must remain the same across all its versions; changing the referenced workflow (even just the version) is considered a structural change and requires a new launch plan name. This ensures reproducibility and traceability of executions, as each launch plan name consistently maps to a specific workflow structure over time. See launch_plan_test.go and errors_test.go. A practical approach is to encode the workflow version or a semantic identifier in the launch plan name (e.g.,

my_lp_v1

,

my_lp_v2

). This allows you to register and activate new launch plans for updated workflow versions without conflicting with previous ones. You can then deactivate or archive old launch plans as needed, keeping your project organized and ensuring that scheduled or manual executions always use the intended workflow version. Sources: - https://github.com/flyteorg/flyte/issues/5073 - https://github.com/flyteorg/flyte/issues/3109 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 what is the purpose of versioning a named

LaunchPlan

if the underlying workflow can't change between versions?

The purpose of versioning a named

LaunchPlan

is to allow updates to its configuration—such as default or fixed inputs, schedules, notifications, labels, or other runtime overrides—while keeping the underlying workflow structure constant. This enables you to iterate on operational aspects (e.g., change a schedule or notification policy) without altering the workflow logic itself. The workflow reference (project/domain/name/version) must remain the same for all versions of a given launch plan name, ensuring structural consistency and reproducibility. See launch_plan_test.go and errors_test.go. If you need to point to a new workflow version, you must create a new launch plan name. Versioning is thus intended for managing changes to launch plan metadata and operational parameters, not for changing the workflow it executes. Sources: - https://github.com/flyteorg/flyte/issues/5073 - https://github.com/flyteorg/flyte/issues/5415 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@brief-family-9488 you probably already came to this conclusion

This is interesting, we register a new version of a workflow and LaunchPlan together and never had to change the name of the LaunchPlan when I register a new workflow version.