We're seeing a bit of a discrepancy around how agents handle an "aborted" status... partly because I think Flyte only understands "abort" at the execution level, rather than at the task level. In a simple example, assume that Flyte is executing a workflow with many tasks that each trigger agents. In the "remote" system, the user can stop / abort the task and that status propagates back to the Flyte agent as you'd expect. However, propeller then treats that status as failed --- which effectively misreports the status inside Flyte from a user perspective. (see https://github.com/flyteorg/flyte/blob/5b0d78715c31824f0af156c92fa4fe8971a412a5/flyteplugins/go/tasks/plugins/webapi/agent/plugin.go#L275-L276) Is this something that has been given any thought? Should the current behavior change to better handle this scenario?

if someone aborts it externally that is failure from flyte's pov

One of my colleagues started hacking on a solution like this -- https://github.com/flyteorg/flyte/pull/5566 Sounds like you think this is the wrong direction given the design of Flyte?