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

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

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            medianick 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.

            Show
            medianick 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.
            Hide
            medianick 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.

            Show
            medianick 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.
            Hide
            spencermalone Spencer Malone added a comment - - edited

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

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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: