argoproj / argoproj/argo-workflows

Make `shutdown` parameter available to exit-handler

Open
#5,936 4 comments 4 reactions 0 assignees View on GitHub
area/exit-handler area/shutdown
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.