The waitUntil function calls the WaitForConditionStep class which implements a loop that alternates between a sleep section and the execution of a user specified code section which results in a boolean. In order not to overload the system, the loop time is gradually increased using a muliplication factor of 1.2 (constant RECURRENCE_PERIOD_BACKOFF) and a starting delay time of 250 ms (MIN_RECURRENCE_PERIOD). However, there is no upper limit defined. In the code for the WaitForConditionStep, there is even a comment that questions whether a maximum would be useful.

In the implementation we want to achieve, such upper limit for the recurrence period is mandatory. The cumulative delays can reach more than one day. A relatively simple calculation shows that after one day the recurrence periode has increased to at least one hour, en could easily reach more than 3 hours. This is practically unacceptable.

The recommended solution would then be to have a parameter on the waitUntil call. The suggested name is MaxRecurrencePeriod. If no value is given or if 0 is given, there would be no upper limit on the recurrence period (behaviour as is today). If a value is given, it would be the upper limit of the recurrence period in seconds.

Please note that this improvement would also allow for an easy work around for issue
JENKINS-30269. With the below code, the functionality requested in that ticket can be obtained. Please note that it circumvents the comment regarding LockableResource being transient by using temporary objects (hence the null assignments). The code is just an example (no testing whether te resource exists etc).

import org.jenkins.plugins.lockableresources.*;

def resName = "testres1"

echo "Wait for resource " + resName

waitUntil {
def lrm = LockableResourcesManager.get()
def lr = lrm.fromName(resName)
def resReserved = lr.isReserved()
lrm = null
lr = null

return !resReserved
}

Thanks!