argoproj / argoproj/argo-workflows
Make failures accessible to later steps
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
{{workflow.failures}} is a great way for exit handlers to diagnose problems with their workflows, but requires you to use the exit handler structure and only apply on the entire workflow. The same information should be made accessible to later steps via manually-defined exit handlers that utilize `continueOn: {failed: True}`.
# Motivation
Exit handlers don't work properly with WorkflowTemplates (#2831), and are seen as a ["superfluous" and "essentially a convenience feature"](https://github.com/argoproj/argo/pull/1716#issuecomment-555631825). However, the `{{workflow.failures}}` variable is only accessible to exit handlers, so any attempt to diagnose failures using Argo must route through them. It would be better if there were another way to get the same information.
# Proposal
Simple: Just give the same JSON string to `{{steps.STEP.failures}}`, `{{tasks.TASK.failures}}` for downstream steps/tasks to process. The docs should explain that you need to use `continueOn` for those steps to even run, but that's already true for the similar `exitCode` parameter coming out in v2.8. They also should clarify that there can be multiple failures if the reference step/task is itself a steps or DAG template, which is why it is `failures`, plural.
---
**Message from the maintainers**:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
Contributor guide
Research direction
Start by tracing how workflow.failures, steps.STEP.failures, and tasks.TASK.failures are handled, then review the documentation for continueOn and exitCode. Define completion as downstream steps and tasks receiving the proposed JSON failure information, with documentation covering continueOn and multiple failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, devops
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100