Proposal
Hello everyone,
i observe the following behavior:
A job in Azure Devops is available. KEDA schedules a job because the queue length is 1.
The agent job starts and sets the fields receiveTime and lockedUntil.
In the next poll of KEDA another agent job is scheduled since the queue is not empty.
This repeats until the first job succeded leaving lots of dangling jobs.
My proposal would be to check whether receivedTime is nil too in line 432 of the scaler definition to prevent this behavior.
Best regards
Marc
Use-Case
This would help because agents wouldn't be spawned which don't do anything but count to the max parallel jobs which are billed by Azure Devops.
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response
Proposal
Hello everyone,
i observe the following behavior:
A job in Azure Devops is available. KEDA schedules a job because the queue length is 1.
The agent job starts and sets the fields receiveTime and lockedUntil.
In the next poll of KEDA another agent job is scheduled since the queue is not empty.
This repeats until the first job succeded leaving lots of dangling jobs.
My proposal would be to check whether receivedTime is nil too in line 432 of the scaler definition to prevent this behavior.
Best regards
Marc
Use-Case
This would help because agents wouldn't be spawned which don't do anything but count to the max parallel jobs which are billed by Azure Devops.
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
No response