Flyte enables production-grade orchestration for machine learning workflows and data processing created to accelerate local workflows to production.

Flyte

(cross-posted from <#CREL4QVAQ|flytekit> as suggested)

Hi all,
I'm looking for a way to cancel a workflow from within a task, so it stops and goes into the `aborted` state, not `failed`. Is it possible to trigger that from flytekit somehow?

Background is that based on a precondition like too few data points, I don't want to trigger a training task, and `aborted` would be perfect to communicate that it's not a failure, but still didn't run.

Hey! How about a conditional workflow?
<https://docs.flyte.org/projects/flytekit/en/latest/generated/flytekit.conditional.html#flytekit.conditional>

Let’s say you have an ETL and then based on some condition, you may want to (or not) trigger a training task.
You can:
a) Have a condition and try not triggering anything
b) Have a condition and trigger a dummy task named “Training skipped” if you want to have the task

Thanks <@U04P5R3PJ2J> a) sounds interesting. I don't even want to start the training task and I don't need to return anything from the workflows except the reason for canceling. I didn't know I could "not trigger anything" based on a condition. I'll have a look.

The other thing is that I need to run some preprocessing task to inspect the values to decide if the condition holds. That's why I was looking for a way to trigger abort from within that *task* .

In a general way, if this is an ML pipeline, you can think of:
ETL -&gt; Validate Dataset -&gt; Training …

Or maybe something like:
ValidatePreconditions -&gt; ETL -&gt; Validate Dataset -&gt; Training …

However you design it, you can have a boolean task <https://docs.flyte.org/projects/cookbook/en/latest/auto_examples/advanced_composition/conditions.html#using-the-output-of-a-previous-task-in-a-conditional|like in this example>

Personal opinion: I’d always have at least a task where this validation is done, so that you can implement logs, metrics, etc, to track what happened and why did you (or you did not) move forward in the pipeline

I like that :point_up: however, you can't really "abort" the workflow... you can either make it succeed or fail with a non-retriable error... in case of succeeded, you will be able to look at the graph of the execution and tell that the entire training task branch hasn't executed but it won't be obvious from the executions list view...

Short of using FlyteRemote from within the task (ugly), there isn't a way to abort the workflow. Maybe there should be a special kind of an exception to throw to indicate "Skipped, Aborted..." or something like that..