You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have tested with the :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.
I have searched existing issues and could not find a match for this bug
When running a DAG step which has an initContainer, and the initContainer fails, then the other containers in the containerSet are never scheduled/never run and the Workflow hangs indefinitely.
Note that the workflow fails as expected when using a container + initContainer, so this is specifically inconsistent only when using a containerSet.
Version(s)
v3.6.4
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.
Error from server (BadRequest): container "wait" in pod "hello-world-containerset-initcontainerfails-ck7b8-foo-template-863968479" is waiting to start: PodInitializing
The text was updated successfully, but these errors were encountered:
@chengjoey I've tested it with the latest(main) and reproduced it. However, the workflow will not stuck running indefinitely, it will fail on the next resync. #13858 also mentioned this issue, but the focus was not on workflow stucking.
jswxstw
added a commit
to jswxstw/argo-workflows
that referenced
this issue
May 27, 2025
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?
When running a DAG step which has an initContainer, and the initContainer fails, then the other containers in the containerSet are never scheduled/never run and the Workflow hangs indefinitely.
Note that the workflow fails as expected when using a
container
+initContainer
, so this is specifically inconsistent only when using acontainerSet
.Version(s)
v3.6.4
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow 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: