@ancient-wolf-19325 We have a scheduled inference system where we register and activate new LaunchPlan versions frequently (on every main branch merge). I want to understand the safety guarantees around this pattern. 1. If a LaunchPlan is currently executing a workflow (triggered by its CronSchedule), and we register a new version of that LaunchPlan and activate it, what happens to the currently running execution? Does it continue unaffected, or can it be interrupted/cancelled? 2. When the CronSchedule fires, is there any risk that both the old (previously active) and new (just activated) LaunchPlan versions could be triggered simultaneously if the timing is tight? 3. Does Flyte have any built-in protection (e.g., idempotency keys, deduplication) that prevents both versions from executing if they happen to be triggered at the same time? 4. What's the recommended way to deploy updates to a LaunchPlan that has an active CronSchedule without disrupting in-flight executions?

It seems likely that when you activate a new LaunchPlan version, any currently running executions from the previous version will continue unaffected; Flyte does not interrupt or cancel in-flight executions when a new version is activated. Activation only affects which version is used for future scheduled runs, not those already started (flyteadmin/pkg/manager/impl/launch_plan_manager.go, flyteadmin/tests/launch_plan_test.go). My understanding is that only one LaunchPlan version can be active at a time for a given (project, domain, name), and activating a new version automatically deactivates the previous one. The scheduler will only trigger the currently active version, so there should not be a risk of both old and new versions being triggered simultaneously, even if the activation timing is close (flyteidl/service/admin_pb2.py, docs/user_guide/productionizing/schedules.md). Flyte's scheduler uses idempotency based on a hash of schedule time and launch plan identifier, which helps prevent duplicate executions if there are race conditions or scheduler restarts (flyteadmin/scheduler/doc.go). The recommended way to update a LaunchPlan with an active schedule is to register the new version and activate it; this will safely switch future scheduled runs to the new version without disrupting in-flight executions (docs/user_guide/productionizing/schedules.md). Would you like more detail on any specific aspect, such as scheduler internals or the activation process? Sources: - flyteadmin/pkg/manager/impl/launch_plan_manager.go - flyteadmin/tests/launch_plan_test.go - flyteidl/service/admin_pb2.py - docs/user_guide/productionizing/schedules.md - flyteadmin/scheduler/doc.go 👍 2 button 👎 0 button 💡 Hint: Mention @ancient-wolf-19325 in the thread for followups.

Is there a way to manually launch a launchplan (independent of it's scheduled time?) @ancient-wolf-19325

Yes, you can manually launch a LaunchPlan independently of its scheduled time using either the FlyteRemote Python API or the flytectl CLI. This allows you to trigger executions on demand, regardless of any schedule attached to the LaunchPlan (docs/user_guide/development_lifecycle/running_launch_plans.md). For example, with FlyteRemote:

from flytekit.remote import FlyteRemote
from flytekit.configuration import Config

remote = FlyteRemote(
    config=Config.for_endpoint(endpoint="flyte.example.net"),
    default_project="flytesnacks",
    default_domain="development",
)

flyte_lp = remote.fetch_launch_plan(
    name="workflows.example.wf", version="v1", project="flytesnacks", domain="development"
)
execution = remote.execute(flyte_lp, inputs={"mean": 1}, execution_name="lp-execution", wait=True)

Would you like more detail or examples using the CLI? Sources: - docs/user_guide/development_lifecycle/running_launch_plans.md 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.