argoproj / argoproj/argo-workflows
Make `shutdown` parameter available to exit-handler
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
We need to be able to detect in the exit-handler whether the workflow has been STOPped or not. Currently, this is not possible, since when the 'exit-handler' is invoked, the Workflow object's `status` structure is not yet finalized, the workflow's and last steps' states are still `Running`. The only way to know the final Workflow status is the `{{workflow.status}}` & `{{workflow.failures}}` variables that can be added as step parameters. However, there is currently no way to know the `shutdown` flag's value, that is normally available on a finished workflow at `workflow.status.shutdown`.
@alexec's initial suggestion was to detect the stop from workflow steps (by detecting SIGTERM signals, which we do), then make an output parameter based on that, which then is available to the exit-handler. However, that doesn't look like an ultimate solution as the step(s) doing this detection might fail to start for various reasons.
My suggestion is to make the shutdown field available to the 'exit-handler', similarly how the final status & list of failures.
# Use Cases
The 'exit-handler' is typically used to react to the workflow's status as a final step, usually pushing a final state update of the workflow to various backend system(s). Since we support "STOP" as a user-action, we need to be able to show proper "CANCELLED" status for workflows that have been stopped.
---
**Message from the maintainers**:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
Contributor guide
Research direction
Start by tracing how the exit-handler receives workflow.status and workflow.failures, then follow the workflow object's status finalization and shutdown handling. Confirm how a STOP action is represented before the exit-handler runs. Done means the exit-handler can access workflow.status.shutdown and distinguish a stopped workflow from other final states.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100