We're seeing launch plan versions pile up in Flyte Admin — every

pyflyte register

creates new versions and nothing cleans up the old ones. Over time this adds up: more data to page through, heavier queries, more memory pressure on Admin. Has anyone dealt with this? We're thinking about a script to deactivate old versions (keep the most recent N, never touch the active one), but curious if there's a better pattern or something built into Flyte we're missing. Why it matters for us: We discover downstream workflows by calling

ListLaunchPlans

filtered on

workflow.short_description

, sorted by created_at DESC. The filter returns all versions of matching launch plans, not just the active one — so if a workflow has 30 versions from 30 deploys, that's 30 rows even though only the latest matters. Question on cleanup: Is there a way to actually delete old launch plan versions via the Admin API, or is UpdateLaunchPlan to set state INACTIVE the only option? If we deactivate old versions, does filtering with

eq(state,1)

reliably exclude them? For reference, our query looks like:

ListLaunchPlans(ResourceListRequest {
  id: NamedEntityIdentifier { domain: "production", project: "my-project" }
  sort_by: Sort { key: "created_at", direction: DESCENDING }
  limit: 50
  filters: "contains(workflow.short_description,triggered_by.workflow=my_upstream)"
  token: ""
})

We'd like to either delete old versions outright or mark them state=0 and filter with

eq(state,1)

going forward.

Blake we are focused on v2.0 now. It should be ok to delete lps from db or you might need a contribution to remove

Alright. Yea, we've already created the workflow to use the db to mark things as

ARCHIVED

but we were hoping to use the API. We still get to check

ne(state,2)

which helps on our end. Looking forward to the v2

Ya it's ok to delete old entries