Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-71920

Retry option doesn't respect timeout in declarative pipeline

      The following pipeline succeeds, even though `sleep` times out on the first try. It appears that the second try ignores the `timeout` option.

      pipeline {
          agent none
          stages {
              stage('With timeout') {
                  options {
                      retry(2)
                      timeout(time: 5, unit: 'SECONDS')
                  }
                  steps {
                      sleep time: 10, unit: 'SECONDS'
                  }
              }
          }
      }
      

          [JENKINS-71920] Retry option doesn't respect timeout in declarative pipeline

          Victor Balakine created issue -

          Bruno Verachten added a comment - - edited

          Here's what I think happens in your pipeline:

          1. The stage starts, and the timeout is set for 5 seconds.
          2. The sleep step starts, which sleeps for 10 seconds.
          3. After 5 seconds, the timeout is reached, and the first attempt of the stage is aborted.

          However, the retry step kicks in and retries the entire stage because it's considered a single unit. The timeout option doesn't reset for each retry; it applies to the cumulative time spent in all attempts of the stage. Since the cumulative time spent in both attempts exceeds 5 seconds, the stage ultimately succeeds after the second try.

          If you want to apply a timeout to each individual retry attempt, you may need to structure your pipeline differently, such as putting the timeout inside the retry block like this:

          pipeline {
              agent none
              stages {
                  stage('With timeout') {
                      options {
                          retry(2) {
                              timeout(time: 5, unit: 'SECONDS')
                          }
                      }
                      steps {
                          sleep time: 10, unit: 'SECONDS'
                      }
                  }
              }
          }

          With this configuration, each retry attempt should have its own 5-second timeout, and if the sleep step exceeds that time on any attempt, that individual attempt will be aborted.

          Bruno Verachten added a comment - - edited Here's what I think happens in your pipeline: The stage starts, and the timeout is set for 5 seconds. The sleep step starts, which sleeps for 10 seconds. After 5 seconds, the timeout is reached, and the first attempt of the stage is aborted. However, the retry step kicks in and retries the entire stage because it's considered a single unit. The timeout option doesn't reset for each retry; it applies to the cumulative time spent in all attempts of the stage. Since the cumulative time spent in both attempts exceeds 5 seconds, the stage ultimately succeeds after the second try. If you want to apply a timeout to each individual retry attempt, you may need to structure your pipeline differently, such as putting the timeout inside the retry block like this: pipeline {     agent none     stages {         stage( 'With timeout' ) {             options {                 retry(2) {                     timeout(time: 5, unit: 'SECONDS' )                 }             }             steps {                 sleep time: 10, unit: 'SECONDS'             }         }     } } With this configuration, each retry attempt should have its own 5-second timeout, and if the sleep step exceeds that time on any attempt, that individual attempt will be aborted.

          Thank you poddingue, I understand how it works, I just happen to disagree with it. It is not self evident that timeout in options applies to the stage as a whole, but retry in options applies only to steps block. Besides, it's easier to reason about how much the stage should realistically take and set the appropriate timeout. Think about retrying a network call with Apache HttpClient or OkClient - do you specify total timeout for all attempts or timeout per attempt?

          Victor Balakine added a comment - Thank you poddingue , I understand how it works, I just happen to disagree with it. It is not self evident that timeout in options applies to the stage as a whole, but retry in options applies only to steps block. Besides, it's easier to reason about how much the stage should realistically take and set the appropriate timeout. Think about retrying a network call with Apache HttpClient or OkClient - do you specify total timeout for all attempts or timeout per attempt?

            Unassigned Unassigned
            victor_yousician Victor Balakine
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: