Skip to content

feat(idl): task aliases — mutable named pointers to immutable versions - #8013

Draft
dansola wants to merge 1 commit into
mainfrom
danielsola/task-aliases-pinned
Draft

feat(idl): task aliases — mutable named pointers to immutable versions#8013
dansola wants to merge 1 commit into
mainfrom
danielsola/task-aliases-pinned

Conversation

@dansola

@dansola dansola commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Why are the changes needed?

There is no first-class way to say "production runs this version" and change it later. An external caller — a Lambda, an event bus, a scheduler outside Flyte — must name something stable, and an operator must be able to move what that name resolves to.

Flyte 1 had this as launch plan activation: registering a new version was inert, and activation was the deliberate act that changed what production ran. Flyte 2 has no equivalent. The only way to build it today is to exploit task-version mutability — deploy the same code twice, once under an immutable tag and once under a label like prod, and have the caller pin version="prod". That is an overwrite rather than a pointer: nothing links prod to the version it stands for, there is no history of who moved it, rolling back means redeploying an old commit under the label, and a run's stored version: "prod" no longer identifies the code that ran.

The same shape exists across the ecosystem — Lambda versions and aliases, image digests and tags, git commits and branches. In every case the mutable name is a separate object from the immutable artifact.

Raised by a team running event-driven pipelines where an AWS Lambda fires a pipeline by name and operators need to control which code version it reaches.

What changes were proposed in this pull request?

Two proto files; the rest of the diff is generated (10 files).

TaskIdentifier gains an alias selector (flyteidl2/task/task_definition.proto)

string version = 5 [(buf.validate.field).string.max_len = 63];
string alias   = 6 [(buf.validate.field).string.max_len = 63];

with a message-level CEL rule requiring exactly one of the two. Putting the selector on the identifier means every RPC that already takes one resolves an alias for free — GetTaskDetails, CreateRun, and later triggers.

Two deliberate choices worth reviewing:

  • Not a oneof. Folding the existing version into one is wire-compatible but changes the generated Go and Python accessors, breaking every caller. A second field plus a CEL constraint gets the same guarantee without the churn.
  • version loses its per-field min_len. An alias-selected identifier leaves version unset, and proto3 renders that as "", which min_len = 1 rejects. The message-level rule now carries that requirement instead, so the constraint is preserved rather than dropped.

Five RPCs on TaskService (flyteidl2/task/task_service.proto): SetTaskAlias, GetTaskAlias, ListTaskAliases, DeleteTaskAlias, GetTaskAliasHistory, plus TaskAliasName, TaskAlias, and TaskAliasRevision.

SetTaskAliasResponse carries previous_version so a client can render prod: v1.4.0 -> v1.7.0 without a second read. Aliases are scoped per (org, project, domain, task_name), so prod in staging and prod in production are distinct pointers.

Server-side implementation is in the Union cloud repo; this PR is the contract only.

How was this patch tested?

Generated with the repo's own CI image (ghcr.io/flyteorg/flyte/ci:latest) via make buf-go and make buf-python, so check-generate should be satisfied. buf lint and buf format -w clean.

The contract was exercised end to end against a live backend built from these protos (a k3d devbox running the cloud implementation): a Go integration test drives all five RPCs plus alias-selected GetTaskDetails, and a Python script drives the same flow through real deploys and real task runs. Both pass. Details and output are in the companion cloud PR's test plan.

Labels

Please add one or more of the following labels to categorize your PR:

  • added: For new features.
  • changed: For changes in existing functionality.
  • deprecated: For soon-to-be-removed features.
  • removed: For features being removed.
  • fixed: For any bug fixed.
  • security: In case of vulnerabilities

This is important to improve the readability of release notes.

Setup process

Screenshots

Check all the applicable boxes

  • I updated the documentation accordingly.
  • All new and existing tests passed.
  • All commits are signed-off.

Related PRs

flyteorg/flyte-sdk#1565
https://github.com/unionai/cloud/pull/18303

Stack

If you do use git town to manage PR Stacks, the stack relevant to this PR
will show below. Otherwise, you can ignore this section.

Docs link

Signed-off-by: Daniel Sola <daniel.sola@union.ai>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant