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

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

XMLWordPrintable

      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.

          [JENKINS-37998] Warning log "no flow execution found for pipelinejob #1"

          Baptiste Mathus created issue -
          Jesse Glick made changes -
          Labels Original: pipeline
          Jesse Glick made changes -
          Issue Type Original: Task [ 3 ] New: Bug [ 1 ]
          Jesse Glick made changes -
          Epic Link New: JENKINS-35399 [ 171192 ]

          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). svanoort 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()) {

          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). svanoort 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()) {
          Jesse Glick made changes -
          Component/s New: pipeline-input-step-plugin [ 21708 ]
          Component/s Original: pipeline [ 21692 ]
          CloudBees Inc. made changes -
          Remote Link New: This issue links to "CloudBees Internal CD-48 (Web Link)" [ 19127 ]

          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)...

          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)...

          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.

          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.
          Jesse Glick made changes -
          Remote Link New: This issue links to "PR 3 (Web Link)" [ 22325 ]

            jglick Jesse Glick
            batmat Baptiste Mathus
            Votes:
            9 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: