Cannot transition status via :enqueue from :pending

[keestux]

Issue

There are error messages in the Jenkins log of the Gitlab plugin. However, the plugin seems to be doing everything it needs to do. When the plugin wants to update the Gitlab pipeline it gets a reply

Cannot transition status via :enqueue from :pending (Reason(s): Status cannot transition via "enqueue")

Context

• Gitlab plugin version: 1.5.9
• Gitlab version: 11.2.3-ee
• Jenkins version: 2.121.3
• Job type: Pipeline

Logs & Traces

In the Jenkins log for each trigger there is a an error with these details

Response body: {
  "message" : "Cannot transition status via :enqueue from :pending (Reason(s): Status cannot transition via \"enqueue\")"
}

Failed to update Gitlab commit status for project '118'
javax.ws.rs.BadRequestException: HTTP 400 Bad Request
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:197)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.DefaultEntityExtractorFactory$3.extractEntity(DefaultEntityExtractorFactory.java:50)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:64)
...

Problem description

As far as I can see, everything works as expected. The Jenkins pipeline is triggered the way it should. In GitLab the pipeline is correctly marked as passed. It's just that the Jenkins log shows this error.

[omehegan]

@keestux I am not sure why you would be seeing this - GitLab is responding in an unexpected way, but you may need to ask them what is causing that.

[alexcern]

Hi,

We've seen this error as well. In our case it was due to the Jenkins web hook being registered twice for the Merge Request events in the GitLab project settings.

[ababushk]

It's not the issue in plugin itself. We see this usually when two or more builds of our pipeline start fast enough (and due to #926 and #871 it happens quite often). Plugin tries to update status and GitLab API doesn't allow some status changes like from 'running' back to 'enqueue' to be made:

Got response from GitLab:
URL: https://gitlab-example.com/api/v4/projects/834/statuses/c476bf95fb62df6a2e75c3e1e69a75c0dd89ce98
Status: 400 Bad Request
Response headers: [
Cache-Control = [no-cache],
Connection = [keep-alive],
Content-Length = [119],
Content-Type = [application/json],
Date = [Fri, 01 Nov 2019 12:19:36 GMT],
Server = [nginx],
Vary = [Origin],
X-Content-Type-Options = [nosniff],
X-Frame-Options = [SAMEORIGIN],
X-Request-Id = [gQxE1SWjDP8],
X-Runtime = [0.486047]
]
Response body: {
  "message" : "Cannot transition status via :enqueue from :running (Reason(s): Status cannot transition via \"enqueue\")"
}
Nov 01, 2019 12:17:54 PM SEVERE com.dabsquared.gitlabjenkins.util.CommitStatusUpdater updateCommitStatus
Failed to update Gitlab commit status for project '834'
javax.ws.rs.BadRequestException: HTTP 400 Bad Request
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:197)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.DefaultEntityExtractorFactory$3.extractEntity(DefaultEntityExtractorFactory.java:50)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
	at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:64)
	at com.dabsquared.gitlabjenkins.gitlab.api.impl.$Proxy135.changeBuildStatus(Unknown Source)
	at com.dabsquared.gitlabjenkins.gitlab.api.impl.ResteasyGitLabClient.changeBuildStatus(ResteasyGitLabClient.java:60)
	at com.dabsquared.gitlabjenkins.util.CommitStatusUpdater.updateCommitStatus(CommitStatusUpdater.java:85)
	at com.dabsquared.gitlabjenkins.util.CommitStatusUpdater.updateCommitStatus(CommitStatusUpdater.java:97)
	at com.dabsquared.gitlabjenkins.workflow.GitLabBuildsStep$GitLabBuildStepExecution$1.onStart(GitLabBuildsStep.java:85)
	at org.jenkinsci.plugins.workflow.cps.CpsBodyExecution.launch(CpsBodyExecution.java:135)
	at org.jenkinsci.plugins.workflow.cps.CpsBodyInvoker.launch(CpsBodyInvoker.java:182)
	at org.jenkinsci.plugins.workflow.cps.DSL$ThreadTaskImpl.invokeBody(DSL.java:648)
	at org.jenkinsci.plugins.workflow.cps.DSL$ThreadTaskImpl.eval(DSL.java:615)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:196)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:370)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:282)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:270)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:66)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)