Search

It looks like the org.jenkinsci.plugins.workflow.steps.FlowInterruptedException exception could be the  cause. If the timeout directive would throw another exception, would this solve the issue?

If capturing the `FlowInterruptedException` it will retry also when aborting the job for any other reason, like canceling. Definitively, timeout should thow a different exception.

I can reproduce this error in a scripted pipeline as well.

As a workaround, I was able to catch FlowInterruptedException and rethrow a more generic exception:

import org.jenkinsci.plugins.workflow.steps.FlowInterruptedException

retry(3) {
  try {
    timeout(time: 10, unit: 'MINUTES') {
      [..]
    }
  } catch (FlowInterruptedException e) {
   // Work around https://issues.jenkins-ci.org/browse/JENKINS-51454
    error 'Timeout has been exceeded'
  }
}

I think there are two desired behaviors depending on the placement of timeout and retry relative to each other.

First case (this ticket):

retry(3) {
  timeout(time: 5, unit: 'MINUTES') {
    // Something that can fail
  }
}

In this case, if the timeout triggers, I think the desired behavior is for retry to run its body again. This is not the current behavior.

Second case (not this ticket):

timeout(time: 5, unit: 'MINUTES') {
  retry(3) {
    // Something that can fail
  }
}

In this case, if the timeout triggers, I think the desired behavior is for retry to be aborted without retrying anything. This is the current behavior, and as far as I understand, is working as-designed after JENKINS-44379.

Switching timeout to use a different kind of exception would fix the first case, but break the second case. To support both use cases, something more complex would be needed (see PR 81 for a possible approach, although retry would need to be updated as well)). basil Noted that a fix for JENKINS-60354 might overlap a bit with this issue.

FWIW: I did a slight modification to the initial workaround and added it to our global shared libraries as retryEvenOnTimeout.
 
It's slightly more robust:

def call(Map retryOptions, Closure closure) {
    retry(retryOptions) {
        try {
            closure()
        } catch(org.jenkinsci.plugins.workflow.steps.FlowInterruptedException ex){
            def causes = ex.getCauses()
            if(causes.find { ! (it instanceof org.jenkinsci.plugins.workflow.steps.TimeoutStepExecution$ExceededTimeout) }) {
                throw ex
            }
            // Wrap the real exception and throw a RuntimeException that'll trigger the retry
            throw new RuntimeException(ex)
        }
    }
}

Other potential solution options are to merge retry and timeout functionality to be able to allow the user to have the option of which functionality they need.

pixman20 Your retryEvenOnTimeout didn't quite work for me, but it did when I replaced "Map retryOptions" with "int retryCount":

def call(int retryCount, Closure closure) {
    retry(retryCount) {
        try {
            closure()
        } catch(org.jenkinsci.plugins.workflow.steps.FlowInterruptedException ex){
            def causes = ex.getCauses()
            if(causes.find { ! (it instanceof org.jenkinsci.plugins.workflow.steps.TimeoutStepExecution$ExceededTimeout) }) {
                throw ex
            }
            // Wrap the real exception and throw a RuntimeException that'll trigger the retry
            throw new RuntimeException(ex)
        }
    }
}

Fixed in jenkinsci/workflow-basic-steps-plugin#144. Released in 2.24.