New RunLLM response generated: >>>*# Question* Hey folks.. we have a workflow that was failing (due to erroneous code), so a team member tried aborting through the UI. However it’s been 20 min and the workflow is still stuck in “Aborting” state. Any idea what might be going on? I see this in the propeller logs

CausedByError: Failed to propagate Abort for workflow. Error: 0: 0: 0: 0: 0: 0: 0: [User] malformed dynamic workflow, caused by: Collected Errors: 2

# Answer The issue you're experiencing is likely due to a problem with the propagation of the abort signal in FlytePropeller. According to this discussion, a similar problem was resolved by removing the finalizer from the FlyteWorkflow Custom Resource Definition (CRD). To resolve this, you can manually remove the finalizer from the CRD: 1. Identify the FlyteWorkflow CRD: Use

kubectl get flyteworkflow -n <namespace>

to list the workflows and identify the one stuck in the aborting state. 2. Edit the CRD: Use

kubectl edit flyteworkflow <workflow-name> -n <namespace>

to open the CRD in an editor. 3. Remove the Finalizer: Locate the

finalizers

field and remove it, then save and exit the editor. Would you like more detailed instructions on how to perform these steps? Sources: - Flyte Discussion on Aborting State Slack Link https://flyte-org.slack.com/archives/CP2HDHKE1/p1720478153.981989 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.