-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retrying workflows have short deadline ignoring activeDeadlineSeconds #13044
Comments
argoproj#13044 Signed-off-by: leesungbin <lee@sungbin.dev>
argoproj#13044 Signed-off-by: leesungbin <lee@sungbin.dev>
I want to confirm if I am misunderstanding the In the documentation, it states, "maxDuration is the maximum amount of time allowed for a workflow in the backoff strategy." Based on this, I thought that maxDuration only affects the backoff process. However, in the code, I noticed that argo-workflows/workflow/controller/operator.go Line 1054 in 9cacef3
Is this intentional? |
…ds. Fixes argoproj#13044 Signed-off-by: leesungbin <lee@sungbin.dev>
We may want to reconsider this later within the context of #10341, i.e. if pending and active time are split in two. The backoff |
Pre-requisites
:latest
image tag (i.e.quay.io/argoproj/workflow-controller:latest
) and can confirm the issue still exists on:latest
. If not, I have explained why, in detail, in my description below.What happened/what did you expect to happen?
I expect that the activeDeadlineSeconds parameter should also apply to retrying workflow pod containers. However, it appears that the retrying container has a short deadline of approximately 1 minute.
Additionally, when I set the activeDeadlineSeconds at the template level, the deadline for the first workflow's wait container is set to 0001-01-01 00:00:00 +0000 UTC, while the second workflow's wait container has a deadline of about 1 minute.
Is this behavior intentional?
Below are the logs resulting from setting the workflow level activeDeadlineSeconds.
Version
latest
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: