argoproj / argoproj/argo-workflows

Cronworkflow Using Forbid and specify the deadline will have problem

Open
#10,683 3 comments 0 reactions 0 assignees View on GitHub
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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.