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

Warning log "no flow execution found for pipelinejob #1"

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Hi,

      When testing pipeline's durability, I tried killing a sample running pipeline to see how it behaves.

      After killing forcefully the server, though there seems to me no problem from an UI standpoint, I saw the following log I thought I would report:

      WARNING: no flow execution found for pipelinejob #1
      

      How to reproduce:

      • run a brand new 2.7.3
      • install suggested plugins
      • create a pipeline job with the following script:
      // input normally returns a map, BUT returns directly the value if there's only one param
      def loopCount = input message: 'Continue? If so, how many iterations?', parameters: [string(defaultValue: '', description: '', name: 'loopCount')]
      assert loopCount.isNumber() : "oh noes, beware JENKINS-34488"
      
      stage "looping"
      
      for ( int i=0 ; i< loopCount.toInteger() ; i++) {
          echo "$i"
          sleep 5
      }
      
      • Run the pipeline
      • Answer the input, and put 10 for example
      • Kill -9 the master
      • Restart it
      • Refresh the console
      • See the pipeline finish correctly
      • Go back to the job page
      • See the message: WARNING: no flow execution found for pipelinejob #1
      • (sometimes seems to require two kills to trigger that, still trying to refine the reproduction case)

      WDYT?

      Leaving as minor because as said above, the durability seems still to be working since the pipeline always does restart from where it left in my tests.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            The log message is coming from the input step, so should start there in diagnosis. It is failing to find the current build in FlowExecutionList. That in and of itself is probably correct, since the build has finished at this point, so why is loadExecutions even looking for it? Perhaps it is failing to notice that there are no active ids and thus it needs to do nothing. If so, this is truly trivial (just a warning). Sam Van Oort has the beginnings of a patch to refactor InputAction, which would address this as a side effect, though probably the fix for this issue is much simpler:

            diff --git a/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java b/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java
            index 7d2e829..26d0ab2 100644
            --- a/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java
            +++ b/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java
            @@ -58,6 +58,10 @@ public class InputAction implements RunAction2 {
                 @SuppressFBWarnings(value="EC_UNRELATED_TYPES_USING_POINTER_EQUALITY", justification="WorkflowRun implements Queue.Executable")
                 private synchronized void loadExecutions() throws InterruptedException, TimeoutException {
                     if (executions == null) {
            +            if (ids.isEmpty() || /* fallback */!run.isBuilding()) {
            +                executions = new ArrayList<>();
            +                return;
            +            }
                         try {
                         FlowExecution execution = null;
                         for (FlowExecution _execution : FlowExecutionList.get()) {
            
            Show
            jglick Jesse Glick added a comment - The log message is coming from the input step, so should start there in diagnosis. It is failing to find the current build in FlowExecutionList . That in and of itself is probably correct, since the build has finished at this point, so why is loadExecutions even looking for it? Perhaps it is failing to notice that there are no active ids and thus it needs to do nothing. If so, this is truly trivial (just a warning). Sam Van Oort has the beginnings of a patch to refactor InputAction , which would address this as a side effect, though probably the fix for this issue is much simpler: diff --git a/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java b/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java index 7d2e829..26d0ab2 100644 --- a/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java +++ b/src/main/java/org/jenkinsci/plugins/workflow/support/steps/input/InputAction.java @@ -58,6 +58,10 @@ public class InputAction implements RunAction2 { @SuppressFBWarnings(value= "EC_UNRELATED_TYPES_USING_POINTER_EQUALITY" , justification= "WorkflowRun implements Queue.Executable" ) private synchronized void loadExecutions() throws InterruptedException, TimeoutException { if (executions == null ) { + if (ids.isEmpty() || /* fallback */ !run.isBuilding()) { + executions = new ArrayList<>(); + return ; + } try { FlowExecution execution = null ; for (FlowExecution _execution : FlowExecutionList.get()) {
            Hide
            reinholdfuereder Reinhold Füreder added a comment - - edited

            Actually this (symptom):

            2019-01-29 10:19:40 WARNING [org.jenkinsci.plugins.workflow.support.steps.input.InputAction loadExecutions]   no flow execution found for ACME/ACME-Deployment-Pipeline #131
            

            ... also seems to happen for a scripted pipeline that uses a so-called push button deployment (input step wrapped into timeout) where the deployment is having some parallel steps when:

            • opening the pipeline view in Blue Ocean for a (finished) build
            • opening the activity view (i.e. pipeline overview) in Blue Ocean for this pipeline the first time: here the warning is logged twice for each build (all are finished)

            (Without killing master or restarting or whatever potentially unusual actions)

            And so this leads to really a lot of log spam (at least)...

            Show
            reinholdfuereder Reinhold Füreder added a comment - - edited Actually this (symptom): 2019-01-29 10:19:40 WARNING [org.jenkinsci.plugins.workflow.support.steps.input.InputAction loadExecutions] no flow execution found for ACME/ACME-Deployment-Pipeline #131 ... also seems to happen for a scripted pipeline that uses a so-called push button deployment (input step wrapped into timeout) where the deployment is having some parallel steps when: opening the pipeline view in Blue Ocean for a (finished) build opening the activity view (i.e. pipeline overview) in Blue Ocean for this pipeline the first time: here the warning is logged twice for each build (all are finished) (Without killing master or restarting or whatever potentially unusual actions) And so this leads to really a lot of log spam (at least)...
            Hide
            jglick Jesse Glick added a comment -

            Not sure what the root cause is in your case, but FYI some variant of PR 3 would likely fix this.

            Show
            jglick Jesse Glick added a comment - Not sure what the root cause is in your case, but FYI some variant of PR 3 would likely fix this.
            Hide
            reinholdfuereder Reinhold Füreder added a comment - - edited

            Jesse Glick Thanks for giving me hope

            Frankly I must admit that I am not so sure anymore about the "without [...] or whatever potentially unusual actions", because it does not happen at the moment for the latest builds seemingly; and a small reproducer with just "push button deployment (input step wrapped into timeout)" also failed to produce these warning logs ;-(

            • Hm, this morning the warning logs are appearing!? (I naively guess that yesterday afternoon when I was trying to reproduce them, something was still in memory/cache or so? Again, for newly/just triggered pipeline builds these warnings are not logged)

            In case it is of any help, this is the pipeline script (presumably job properties and build discarder, as well as 'init' stage, or maybe everything outside 'prepare deployment' stage is not needed?):

            #!/usr/bin/env groovy
            
            def jobProperties = [
              buildDiscarder(logRotator(daysToKeepStr: '30', numToKeepStr: '30'))
            ]
            properties(jobProperties)
            
            stage('init') {
              echo 'init'
            }
            
            boolean doDeploy = true
            stage('prepare deployment') {
              try {
                timeout(time:7, unit:'DAYS') {
                  input message:'Deploy?'
                }
              } catch(err) { // timeout reached or input false
                doDeploy = false
              }
            
              if (doDeploy) {
                echo 'prepare something for deployment'
              }
            }
            
            if (doDeploy) {
              stage('do deployment') {
                echo 'doDeployment'
              }
            }
            
            Show
            reinholdfuereder Reinhold Füreder added a comment - - edited Jesse Glick Thanks for giving me hope Frankly I must admit that I am not so sure anymore about the " without [...] or whatever potentially unusual actions ", because it does not happen at the moment for the latest builds seemingly; and a small reproducer with just " push button deployment (input step wrapped into timeout) " also failed to produce these warning logs ;-( Hm, this morning the warning logs are appearing!? (I naively guess that yesterday afternoon when I was trying to reproduce them, something was still in memory/cache or so? Again, for newly/just triggered pipeline builds these warnings are not logged) In case it is of any help, this is the pipeline script (presumably job properties and build discarder, as well as 'init' stage, or maybe everything outside 'prepare deployment' stage is not needed?): #!/usr/bin/env groovy def jobProperties = [ buildDiscarder(logRotator(daysToKeepStr: '30' , numToKeepStr: '30' )) ] properties(jobProperties) stage( 'init' ) { echo 'init' } boolean doDeploy = true stage( 'prepare deployment' ) { try { timeout(time:7, unit: 'DAYS' ) { input message: 'Deploy?' } } catch (err) { // timeout reached or input false doDeploy = false } if (doDeploy) { echo 'prepare something for deployment' } } if (doDeploy) { stage( ' do deployment' ) { echo 'doDeployment' } }
            Hide
            reinholdfuereder Reinhold Füreder added a comment -

            Since massively upgrading Jenkins (core 2.270 => 2.283; 77 plugins!) I stumbled again over this warning message log spam:

            • it accounts for 16488 of 16865 log lines!
              • (I am pretty sure it has nothing to do with the upgrade, because this log spam was there ever since; it is just more massive, but maybe due to our behaviour: see below)

            Admittedly the single pipeline with this "push button deployment (input step wrapped into timeout)" is under heavy development, so I guess that 2-4 colleagues have Jenkins UI for this pipeline opened in 1..N browser windows/tabs...
            Potentially also interesting is, that I am using these non-official API calls (cf. "@Restricted(NoExternalUse.class)" annotation) to allow nice UI for skipped stages in scripted pipelines (like for declarative ones) based on https://github.com/comquent/imperative-when (see https://issues.jenkins-ci.org/browse/JENKINS-47286).

            Thanks for any progress/help to reduce or ideally "just" avoid this log spam

            Show
            reinholdfuereder Reinhold Füreder added a comment - Since massively upgrading Jenkins (core 2.270 => 2.283; 77 plugins!) I stumbled again over this warning message log spam: it accounts for 16488 of 16865 log lines! (I am pretty sure it has nothing to do with the upgrade, because this log spam was there ever since; it is just more massive, but maybe due to our behaviour: see below) Admittedly the single pipeline with this " push button deployment (input step wrapped into timeout) " is under heavy development, so I guess that 2-4 colleagues have Jenkins UI for this pipeline opened in 1..N browser windows/tabs... Potentially also interesting is, that I am using these non-official API calls (cf. "@Restricted(NoExternalUse.class)" annotation) to allow nice UI for skipped stages in scripted pipelines (like for declarative ones) based on https://github.com/comquent/imperative-when (see https://issues.jenkins-ci.org/browse/JENKINS-47286 ). Thanks for any progress/help to reduce or ideally "just" avoid this log spam
            Hide
            tamerlaha ipleten added a comment -

            Yes we have the same problem. And seems it is related to pipelines with input step as Reinhold Füreder mentioned.

            Show
            tamerlaha ipleten added a comment - Yes we have the same problem. And seems it is related to pipelines with input step as Reinhold Füreder mentioned.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              batmat Baptiste Mathus
              Votes:
              7 Vote for this issue
              Watchers:
              14 Start watching this issue

                Dates

                Created:
                Updated: