@ancient-wolf-19325 When using the "relaunch" option in UI, labels that were attached to the original workflow are gone. Can I somehow ensure that labels are kept during relaunch of workflow?

Currently, when you use the "relaunch" option in the Flyte UI, labels attached to the original workflow execution are not automatically persisted to the new execution. This is a known issue and has been reported by users; relaunching does not repopulate all advanced fields, including labels, from the prior execution, which can lead to missing metadata in the relaunched workflow execution. There is no built-in mechanism in the UI to ensure labels are automatically carried over during relaunch as of now, and you would need to manually re-enter them each time you relaunch a workflow execution in the UI. If you need to enforce label persistence, you may consider programmatically launching executions (e.g., via FlyteRemote or CLI) where you can explicitly set labels, or monitor for updates in the Flyte UI that address this limitation. For more details, see the discussion in Flyte issue #1737 and Flyte issue #2. Would you like more detail on possible workarounds or programmatic solutions? Sources: - Flyte issue #1737 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 are there any ways to pass the labels during relaunch of execution?

It seems likely that, as of now, there is no direct way in the Flyte UI to pass or override labels during a relaunch of an execution—labels from the original execution are not automatically carried over, and the UI does not provide a field to set them at relaunch time. However, if you use programmatic interfaces like FlyteRemote or CLI tools, you may be able to specify labels explicitly when creating a new execution, but not when using the built-in "relaunch" feature, which is designed to replicate the original execution's parameters and does not expose label overrides. This limitation is discussed in Flyte issue #1737. Would you like more detail on how to programmatically launch executions with labels as a workaround? Sources: - Flyte issue #1737 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 is there any way for me to tell that given workflow was relaunch of different workflow? So I can use admission webhooks or smth for tht

Yes, when a workflow is relaunched, the new execution contains metadata indicating it is a relaunch and references the original execution. Specifically, the execution spec's metadata includes a mode set to

RELAUNCH

and a reference to the source execution. This information can be accessed programmatically and could be used by admission webhooks to identify relaunches. See execution_manager.go for how the relaunch sets these fields. Would you like more detail on how to extract or use this metadata in a webhook? Sources: - execution_manager.go 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 I can see the ID of original workflow? Or somehow connect it so i cant fetch labels from original workflow and assign them to new one. Any fields in k8 objects allow for that?

Yes, when a workflow execution is relaunched, the new execution's metadata includes a reference to the original execution via the

reference_execution

field in the execution spec's metadata. This field stores the ID of the original workflow execution, allowing you to programmatically connect the new execution to its source and fetch labels or other metadata from the original. This information is available in the FlyteAdmin API and is also reflected in the underlying Kubernetes custom resource for the workflow execution, though not as a direct label but as part of the execution spec metadata (execution_manager.go). Would you like more detail on how to access this field or use it in automation? Sources: - execution_manager.go 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 I relaunched workflow, and I see not a single indication of "relaunch" or any reference to original object in the FlyteWorkflow kubernetes object. Any other ideas how to make it work?

It could be possible that, although the FlyteAdmin API and execution metadata internally track the

reference_execution

for relaunches, this information is not surfaced in the FlyteWorkflow Kubernetes custom resource (CRD) by default. The CRD spec does not appear to include a field or annotation that directly references the original execution or indicates a relaunch, based on available documentation and user reports. This means you likely cannot rely on the FlyteWorkflow K8s object alone to detect relaunches or fetch the original execution ID. Though I'm not entirely certain, it might be that your best option is to use the FlyteAdmin API to correlate executions and retrieve the

reference_execution

field, then use that information to fetch labels or metadata from the original execution. If you need this information in the K8s object for webhook or admission control, you may need to implement a custom process to annotate the CRD at launch time or request this as a feature in Flyte. Would you like more detail on using the FlyteAdmin API for this purpose or on possible custom automation approaches? Sources: - https://github.com/flyteorg/flyte/blob/master/docs/user_guide/productionizing/workflow_labels_and_annotations.md - https://github.com/flyteorg/flyte/issues/6550 Note: I wasn’t able to find highly relevant data sources, but above are a few potentially relevant links. 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 what is the difference between recover and relaunch

The difference is: relaunch creates a new execution with the same inputs as the original, starting from the beginning, while recover creates a new execution that resumes from the last known failure point, skipping successful nodes. In recover mode, you cannot change input parameters or update the workflow version; relaunch allows you to rerun the entire workflow with the same or new parameters (flytectl execution docs, Flyte blog). Would you like more detail or examples of when to use each? Sources: - flytectl execution docs - Flyte blog 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 is there a way to keep multiple flyte configurations in default config file

~/.flyte/config.yml

and using CLI switch between different endpoints for pyflyte cmd?

No, Flyte does not support storing multiple configurations in a single default config file (

~/.flyte/config.yaml

). To switch between different endpoints or environments, you must maintain separate config files and specify the desired one using the

--config

or

-c

flag with the CLI (e.g.,

pyflyte --config my_config.yaml run ...

). There is no built-in context or profile switching mechanism like

kubectl

contexts (flytectl issue #895, flyte issue #412). Would you like more detail on managing multiple config files or automating environment switching? Sources: - flytectl issue #895 - flyte issue #412 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 and there is no workaround for that? literally nothing? I have to keep 2 configfiles forever

Correct, there is no built-in support or official workaround for managing multiple Flyte environments within a single config file or for context switching like

kubectl

. The only supported method is to maintain separate config files for each environment and specify the desired one using the

--config

flag when running commands (e.g.,

pyflyte --config config-dev.yaml run ...

). This limitation is confirmed in flytectl issue #895 and flyte issue #412. Would you like suggestions for simple shell aliases or scripts to make switching easier? Sources: - flytectl issue #895 - flyte issue #412 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 I found out if i Rerun workflow, labels are passed correctly. but If I rerun a task, labels are gone.... can I smoehow relaunch a task as a workflow?

It seems likely that relaunching a task directly does not preserve workflow-level labels, while rerunning the entire workflow does. There is no built-in way to relaunch a single task as a workflow in Flyte; tasks are not standalone workflows and do not inherit workflow-level metadata when relaunched individually. This limitation is discussed in Flyte issue #545 and Flyte issue #256. Would you like more detail on possible workarounds, such as creating a minimal workflow that wraps your task? Sources: - Flyte issue #545 - Flyte issue #256 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 IS the task always part of a workflow? or can I run individual task

You can run an individual task in Flyte; a task does not always have to be part of a workflow. Flyte supports executing single tasks directly, both locally and remotely, using the CLI (

pyflyte run ... task_name ...

) or programmatically. This is documented in Flyte tasks guide and confirmed in Flyte issue #2471. Would you like more detail or example commands for running a single task? Sources: - Flyte tasks guide - Flyte issue #2471 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 when using the CLI of flytectl create execution --relaunch, do I pass execution UUID? like this long string avljk****? I am getting this error: missing entity of type execution with identifier project

Yes, when using

flytectl create execution --relaunch

, you must pass the execution name (UUID-like string, e.g.,

avljk**

), not the full identifier. You also need to specify the correct

-p

(project) and

-d

(domain) flags to match the original execution. The error "missing entity of type execution with identifier project" usually means the execution ID, project, or domain does not match an existing execution (flytectl execution docs). Would you like more detail on how to find the correct execution ID and flags? Sources: - flytectl execution docs 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 what If i do flytectl create execution --relaunch and pass the new execFile, does that update the execution? point me to relevant code in flyte

It seems likely that if you use

flytectl create execution --relaunch

and pass a new

--execFile

, the relaunch will not use the new execFile to update the execution parameters. The relaunch command is designed to replicate the original execution's parameters, and the execFile is ignored in this context. The relevant code in Flyte is in execution_manager.go, where the relaunch logic copies the original execution's spec and inputs, not the new execFile. Would you like more detail on how relaunch works or how to update execution parameters? Sources: - execution_manager.go 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.