argoproj / argoproj/argo-workflows
choose if activeDeadlineSeconds timeout is an error or not
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
What change needs making?
Add a new field to specify the resulting state of an `activeDeadlineSeconds` being reached.
Currently, when `activeDeadlineSeconds` is reached, the workflow is considered a failure but in our case, it is not.
# Use Cases
When would you use this?
We would like to use argo workflow to run reinforcement learning experiments where an algorithm is trying to reach the optimum value for a function, think "teaching a computer to play a game".
The algorithm usually runs for a fixed period of time after it stops, this is what we call training.
After which, we evaluate its progress, maybe fine tune the algorithm or the function.
Finishing training is not a failure, it just finished to train.
I though of running the [timeout](https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html) command inside the container but it requires quite some setup with edges cases that we are not really enthusiastic of dealing with.
I would be happy to contribute code and documentation if this feature is accepted. 😄
---
**Message from the maintainers**:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
Contributor guide
Research direction
The issue names no files, tests, or entry points; begin by locating activeDeadlineSeconds handling and the workflow status propagation path. Clarify the supported resulting states and their downstream effects, with completion defined by documented behavior and regression coverage for the configurable timeout outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100