NullPointerException after upgrade to 1156.v5e9f897ece02

[andreyakostovsap]

Jenkins and plugins versions report

Environment

Jenkins: 2.387.3
OS: Linux - 5.4.0-148-generic
Java: 17.0.7 - SAP SE (OpenJDK 64-Bit Server VM)
---
lockable-resources:1156.v5e9f897ece02

What Operating System are you using (both controller, and any agents involved in the problem)?

Debian 11

Reproduction steps

1. Install plugin version prior to 1156.v5e9f897ece02.
2. Create lockable resource with label test.
3. Upgrade to 1156.v5e9f897ece02.
4. Execute the following pipeline:

node('built-in') {
  Map lockStepConfiguration = [
    label: 'test',
    quantity: 1,
    variable: 'testLock'
  ]

  lock(lockStepConfiguration) {
    sh('printenv | sort')
  }
}

Expected Results

The pipeline to succeed.

Actual Results

[Pipeline] Start of Pipeline
[Pipeline] properties
[Pipeline] node
Running on Jenkins in /home/jenkins/master/workspace/playground/lock.test
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Test)
[Pipeline] lock
Trying to acquire lock on [Label: test, Quantity: 1]
Lock acquired on [Label: test, Quantity: 1]
[Pipeline] {
[Pipeline] }
Lock released on resource [Label: test, Quantity: 1]
[Pipeline] // lock
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: b667b610-c423-4316-acc7-13eb03a698b2
java.lang.NullPointerException: Cannot invoke "java.util.List.iterator()" because the return value of "java.util.Map$Entry.getValue()" is null
	at org.jenkins.plugins.lockableresources.LockStepExecution$1.expand(LockStepExecution.java:158)
	at org.jenkinsci.plugins.workflow.steps.EnvironmentExpander$MergedEnvironmentExpander.expand(EnvironmentExpander.java:112)
	at org.jenkinsci.plugins.workflow.steps.EnvironmentExpander.getEffectiveEnvironment(EnvironmentExpander.java:164)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:81)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:261)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:196)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:124)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1225)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:180)
	at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:163)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:178)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:182)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:152)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
	at playground.WorkflowScript.run(WorkflowScript:33)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:90)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:116)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:85)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:83)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:152)
	at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:146)
	at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:136)
	at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:275)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:146)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:187)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:420)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:330)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:294)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at jenkins.util.ErrorLoggingExecutorService.lambda$wrap$0(ErrorLoggingExecutorService.java:51)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
Finished: FAILURE

Anything else?

I think it is probably caused by #394. It looks like a similar situation to 434#issuecomment-1379559915 - a change to the XML format of the lockable resources configuration file causes existing resources defined in the previous version to stop working after upgrading to the latest version.

[mPokornyETM]

Do you knwo, what was the version before update?

[andreyakostovsap]

Yes, we were on 1150.v59db_2b_994618.

I could not configure lockable resources because of JENKINS-70630, but today I disabled HTTP/2 to try and solve the issue. After I that I was able to add a new lockable resource and saving it seems to have triggered an update of the configuration file, which added the missing attribute and the NPE does not occur anymore:

diff --git a/org.jenkins.plugins.lockableresources.LockableResourcesManager.xml b/org.jenkins.plugins.lockableresources.LockableResourcesManager.xml
index ae5ba585a5..f2a6111750 100644
--- a/org.jenkins.plugins.lockableresources.LockableResourcesManager.xml
+++ b/org.jenkins.plugins.lockableresources.LockableResourcesManager.xml
@@ -1,5 +1,5 @@
 <?xml version='1.1' encoding='UTF-8'?>
-<org.jenkins.plugins.lockableresources.LockableResourcesManager plugin="lockable-resources@1106.vc9153f1a_ff25">
+<org.jenkins.plugins.lockableresources.LockableResourcesManager plugin="lockable-resources@1156.v5e9f897ece02">
   <resources>
     <org.jenkins.plugins.lockableresources.LockableResource>
       <name>tests-integration-installation-0</name>
@@ -8,6 +8,7 @@
       <note></note>
       <stolen>false</stolen>
       <ephemeral>false</ephemeral>
+      <properties/>
       <queueItemId>0</queueItemId>
       <queuingStarted>0</queuingStarted>
       <queuedContexts/>
@@ -21,6 +22,7 @@
...

I think a null check here should restore backwards compatibility.

[srkiNZ84]

This has also affected us. Thank you for the workaround. Adding a new "lockable resource" caused the plugin to re-generate the XML file and add an empty <properties /> element 👍

[mPokornyETM]

Thx for reporting, I thinkg we need little more tests for .xml config files. My local tests was done only with JCaC, because we use it in my company and general it is the best way (currently). I will check it an try to fix it in the next release
@andreyakostovsap thx for the workarrond

[stmlange]

Bumped into this well, thanks for the suggested workaround(s), that did the trick!

If desired I can dig out the previous version (from the backup) that was installed

[vinaykothiyal]

Ran into this issue today, thanks @andreyakostovsap for the workaround! It saved me splitting my hair trying to figure out build will fail even though it would print that lock was acquired.