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

Pipeline build hangs with "Failed to load build state" due to org.acegisecurity.AccessDeniedException

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • None
    • Jenkins 2.32.3 LTS, Pipeline Groovy 2.28, master and slave nodes running Windows Server 2012 R2.

      Update (March 7): See comment below; this seems to be triggered by having two webhooks setup in GitHub Enterprise for the same repository.

      I'm seeing certain pipeline builds hang after upgrading to the set of SCM API 2 plugins; this didn't happen before that upgrade. So far, I've only seen it for build #1 of a multibranch pipeline job (i.e., a new branch or PR). The manifestation is that the build appears to be running under the build node in question, but never completes. (It just shows the striped progress bar perpetually, until aborted.) The console log, however, shows the build as having failed, with this stack trace:

      java.io.IOException: Failed to load build state
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$3.onSuccess(CpsFlowExecution.java:611)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$3.onSuccess(CpsFlowExecution.java:609)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$4$1.run(CpsFlowExecution.java:658)
      	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:35)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      	at java.util.concurrent.FutureTask.run(Unknown Source)
      	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
      	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      	at java.util.concurrent.FutureTask.run(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      	at java.lang.Thread.run(Unknown Source)
      Caused by: org.acegisecurity.AccessDeniedException: Please login to access job My Job Name
      	at jenkins.model.Jenkins.getItem(Jenkins.java:2724)
      	at jenkins.model.Jenkins.getItem(Jenkins.java:324)
      	at jenkins.model.Jenkins.getItemByFullName(Jenkins.java:2830)
      	at hudson.model.Run.fromExternalizableId(Run.java:2314)
      	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.runForDisplay(ExecutorStepExecution.java:384)
      	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getDisplayName(ExecutorStepExecution.java:397)
      	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getFullDisplayName(ExecutorStepExecution.java:406)
      	at org.jenkinsci.plugins.workflow.support.pickles.ExecutorPickle$1.printWaitingMessage(ExecutorPickle.java:116)
      	at org.jenkinsci.plugins.workflow.support.pickles.TryRepeatedly$1.run(TryRepeatedly.java:95)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      	at java.util.concurrent.FutureTask.run(Unknown Source)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
      	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
      	... 3 more

      The text "My Job Name" in the stack trace above replaces the actual job name, although I note that the job name referenced here is actually the parent folder (a standard Cloudbees Folder) containing the multibranch pipeline job, not the multbranch pipeline job itself. 

      When I abort the stuck job, it asks if I want to abort null (possibly because it has already in fact stopped running?), but then it does abort cleanly. Rerunning the job seems to succeed.

          [JENKINS-42504] Pipeline build hangs with "Failed to load build state" due to org.acegisecurity.AccessDeniedException

          Nick Jones added a comment - - edited

          I should add that the stack trace is not always present, but the symptoms are otherwise the same. Sometimes the build appears to hang (perpetual striped progress bar), the build status itself is failed (solid red icon), yet the console log indicates success, e.g.:

          GitHub has been notified of this commit’s build result
          
          Finished: SUCCESS

          The pipeline visualization shows as red, and the hover pop-up shows "Failed with the following error(s)", then a "Windows Batch Script" label with a "Failed to load build state" message following it.

          Nick Jones added a comment - - edited I should add that the stack trace is not always present, but the symptoms are otherwise the same. Sometimes the build appears to hang (perpetual striped progress bar), the build status itself is failed (solid red icon), yet the console log indicates success, e.g.: GitHub has been notified of this commit’s build result Finished: SUCCESS The pipeline visualization shows as red, and the hover pop-up shows "Failed with the following error(s)", then a "Windows Batch Script" label with a "Failed to load build state" message following it.

          Nick Jones added a comment -

          After further investigation, this seems to be the result of having two webhooks set up in GitHub Enterprise – one at the organization level, and one at the repository level. Both fired upon push, resulting in various "CREATED event from" and "REMOVED event from" messages in the branch event log. 

          Having apparently found what is causing this, which is an environmental configuration issue on my side, I'm lowering the priority. There's still something in the GitHub/Pipeline plugin stack that isn't handling this properly, though. Perhaps this will give plugin maintainers enough information to reproduce it.

          Nick Jones added a comment - After further investigation, this seems to be the result of having two webhooks set up in GitHub Enterprise – one at the organization level, and one at the repository level. Both fired upon push, resulting in various "CREATED event from" and "REMOVED event from" messages in the branch event log.  Having apparently found what is causing this, which is an environmental configuration issue on my side, I'm lowering the priority. There's still something in the GitHub/Pipeline plugin stack that isn't handling this properly, though. Perhaps this will give plugin maintainers enough information to reproduce it.

          Spencer Malone added a comment - - edited

          I'm experiencing similar behavior. Anything more we can provide to help expedite this?

          Spencer Malone added a comment - - edited I'm experiencing similar behavior. Anything more we can provide to help expedite this?

            Unassigned Unassigned
            medianick Nick Jones
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: