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
When using the semaphore in combination with a retry strategy, I expect that while the retry backoff other tasks can be processed.
I use argo to process multiple workflows, each having multiple tasks. A semaphore is used to limit the spawning of pods in parallel. Furthermore, a retry policy is used with backoff as the pods rely on other APIs which might restrict access or are not available. The observation is that while a task is sitting out the backoff duration, the semaphore lock is not released and other tasks can't be executed in the meantime. In my opinion, this is not an expected behavior, as it undermines the use of semaphores to regulate the spawning of containers.
To my knowledge it worked before as expected, and I suspect that the following MR reintroduced the current unexpected behavior (I did not test on a previous version) #9063
Version
v3.4.1
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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.
Pre-requisites
:latest
What happened/what you expected to happen?
When using the semaphore in combination with a retry strategy, I expect that while the retry backoff other tasks can be processed.
I use argo to process multiple workflows, each having multiple tasks. A semaphore is used to limit the spawning of pods in parallel. Furthermore, a retry policy is used with backoff as the pods rely on other APIs which might restrict access or are not available. The observation is that while a task is sitting out the backoff duration, the semaphore lock is not released and other tasks can't be executed in the meantime. In my opinion, this is not an expected behavior, as it undermines the use of semaphores to regulate the spawning of containers.
To my knowledge it worked before as expected, and I suspect that the following MR reintroduced the current unexpected behavior (I did not test on a previous version) #9063
Version
v3.4.1
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: