argoproj / argoproj/argo-workflows
Cronworkflow Using Forbid and specify the deadline will have problem
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
### Pre-requisites
- [X] I have double-checked my configuration
- [X] I can confirm the issues exists when I tested with `:latest`
- [ ] I'd like to contribute the fix myself (see [contributing guide](https://github.com/argoproj/argo-workflows/blob/master/docs/CONTRIBUTING.md))
### What happened/what you expected to happen?
Dear:
this is my case: we have many cron workflows . and we using the `Forbid` concurrency stragedy. however, when we specify the activeDeadlineSeconds options , if the workflow instance trigger the timeout , it will leave the pod with `DeadlineExceeded` status.
Then i want that `forbid` concurrency can ignore this DeadlineExceeded instance, and the cron scheduler continue the next run. (we can't use other stragedy because of some reasons) do you have some ideas? may be we should have a stragedy "ForbidIgnoreDeadline"?
### Version
v3.3.10
### 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.
```YAML
spec:
activeDeadlineSeconds: 3600
arguments:
parameters:
- name: hdfs_server
value: nn002.bjb.hadoop:8020
```
### Logs from the workflow controller
```text
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}
```
### Logs from in your workflow's wait container
```text
kubectl logs -n argo -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded
```
Contributor guide
Research direction
Start by reproducing the CronWorkflow with Forbid concurrency and activeDeadlineSeconds as shown, using the workflow-controller logs to confirm the DeadlineExceeded behavior. Trace how the scheduler treats that completed workflow, and consider the expected result: a later run should be permitted without violating Forbid semantics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100