java.lang.IllegalStateException: org.jenkinsci.plugins.workflow.steps.FlowInterruptedException

Google Groups | (JIRA) | 2 months ago
  1. 0

    [JIRA] (JENKINS-37730) DurableTaskStep.Execution hanging after process is dead

    Google Groups | 2 months ago | (JIRA)
    java.lang.IllegalStateException: org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
  2. 0

    Found a case where a {{sh}} step ceased to produce more output in the middle of a command, for no apparent reason, and the build did not respond to normal abort. The virtual thread dump said {code:none} Thread #80 at process (code -1) in /...@tmp/durable-... on ... (pid: ...)) at ... {code} But there is no active CPS VM thread, and nothing visibly happening on the agent, and all {{Timer}} threads are idle. So it seems that a call to {{check}} would have caused the step to fail—but perhaps none came? Possibly {{stop}} should do its own check for a non-null {{Controller.exitStatus}} and immediately fail in such a case (but we run the risk of delivering doubled-up events if {{check}} _does_ run later); or synchronously call {{check}} (though this runs the risk of having two such calls run simultaneously—it is not thread safe); or somehow reschedule it (same problem). At a minimum, the virtual thread dump should indicate what the current {{recurrencePeriod}} is. And the calls to {{schedule}} could save their {{ScheduledFuture}} results in a {{transient}} field, so we can check {{cancelled}} and {{done}} flags. Such diagnostics might make it clearer next time what actually happened. Also a {{term}} claimed to be terminating the {{sh}} step, but the build still did not finish. Again nothing in the physical thread dumps, and virtual thread dump still claims to be inside {{sh}}. System log showed {code:none} ... WARNING org.jenkinsci.plugins.workflow.cps.CpsStepContext onFailure already completed CpsStepContext[186]:Owner[...] java.lang.IllegalStateException: org.jenkinsci.plugins.workflow.steps.FlowInterruptedException at org.jenkinsci.plugins.workflow.cps.CpsStepContext.onFailure( at org.jenkinsci.plugins.workflow.job.WorkflowRun$5.onSuccess( at org.jenkinsci.plugins.workflow.job.WorkflowRun$5.onSuccess( at$ at$SameThreadExecutorService.execute( at$RunnableExecutorPair.execute( at at at at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$5.onSuccess( at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$5.onSuccess( at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$4$ at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$ at java.util.concurrent.Executors$ at at hudson.remoting.SingleLaneExecutorService$ at jenkins.util.ContextResettingExecutorService$ at java.util.concurrent.Executors$ at at java.util.concurrent.ThreadPoolExecutor.runWorker( at java.util.concurrent.ThreadPoolExecutor$ at Caused by: org.jenkinsci.plugins.workflow.steps.FlowInterruptedException at org.jenkinsci.plugins.workflow.job.WorkflowRun.doTerm( at ... {code} So the program state seems to be somehow inconsistent as well; perhaps {{sh}} _did_ complete (it is not shown as in progress in flowGraphTable). Seems that the virtual thread dump needs some kind of fix TBD to better report the real state of a problematic program.

    Jenkins JIRA | 2 months ago | Jesse Glick
    java.lang.IllegalStateException: org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
  3. 0

    Compatability with parallel

    Google Groups | 1 month ago | Unknown author
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    [JIRA] [core] (JENKINS-32783) Deleting a project does not stop all running builds

    Google Groups | 7 months ago | (JIRA)

    Root Cause Analysis

    1. org.jenkinsci.plugins.workflow.steps.FlowInterruptedException

      No message provided

      at org.jenkinsci.plugins.workflow.job.WorkflowRun.doTerm()
    2. org.jenkinsci.plugins
      1. org.jenkinsci.plugins.workflow.job.WorkflowRun.doTerm(
      1 frame