We enabled logging for the CpsStepContext class and got some interesting results:

Apr 08, 2019 12:02:00 PM FINE org.jenkinsci.plugins.workflow.cps.CpsStepContext

no thread 356 among [0, 2, 4, 8, 352, 354, 356]
java.lang.IllegalStateException
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThread(CpsStepContext.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Apr 08, 2019 3:36:03 PM FINE org.jenkinsci.plugins.workflow.cps.CpsStepContext

no thread 296 among [0, 2, 4, 8, 18, 34, 37, 41, 44, 48, 296]
java.lang.IllegalStateException
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThread(CpsStepContext.java:226)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.getThreadSynchronously(CpsStepContext.java:237)
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:298)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.makeLauncher(DefaultStepContext.java:147)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:75)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

In both cases, the thread IDs being looked up do exist in the `threads` TreeSet, but their value is null? But I don't see anywhere where a null value gets inserted into that TreeSet. Could this be a race condition, accessing that value as it's being added/removed by another thread?

We are running into the same issues since updating to Jenkins ver. 2.164.2 and updating all plugins.

I just had a build fail with this problem

java.io.IOException: cannot find current thread
	at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
	at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
	at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
	at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
	at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE 

looking at the class methods where "threads" (a TreeMap) is accessed: https://github.com/jenkinsci/workflow-cps-plugin/blob/f610f0bcf732b13ff542dd4f716d9520988f99a7/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsThreadGroup.java#L186-L205

I see that there is an attempt to ensure that all "put" calls are executed within the same thread – but AFAICT there is no such logic for "get".

Given that TreeMap is NOT a thread-safe class, if calls to "threads.put" and "threads.get" are interleaved, it is entirely possible to get "null" when invoking "get" for a key that has been "put" in another thread.

Even without interleaved execution, I believe it would be possible to get such behavior simply via invoking "put" and "get" in different threads without any synchronization constructs, in terms of the Java Memory Model (but my own memory regarding the JMM is pretty hazy).

In other words, from a glance, it really just looks like "threads" is being manipulated in a non-threadsafe manner.

Can confirm this issue happens in Jenkins 2.168 as well (Centos). We've been running into this daily (several thousand jobs a day, see this at least once or twice a day)

I got this very similar error on Jenkins 2.150.3

It happened at the end of the pipeline.
java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.getListener(DefaultStepContext.java:114)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:79)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.makeLauncher(DefaultStepContext.java:147)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:75)
at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Callback.finished(CoreWrapperStep.java:152)
at org.jenkinsci.plugins.workflow.steps.CoreWrapperStep$Execution2$Callback2.finished(CoreWrapperStep.java:122)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
 

Same issue here:

java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Jenkins: 2.164.1

Groovy: 2.65

Jenkins 2.164.1:

 
15:55:20 ERROR during Build: java.io.IOException: cannot find current thread*15:55:20* at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)15:55:20 at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)15:55:20 at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)15:55:20 at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)15:55:20 at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)15:55:20 at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)15:55:20 at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)

I feel compelled to raise this to major because it's basically causing 25% of our builds to randomly fail & there really isn't a workaround for it.

Again, based on a perfunctory glance at the proximal code (and, admittedly, with absolutely no understanding of the codebase as a whole), I suspect this issue could be fixed by simply synchronizing all access to the underlying "threads" TreeMap.

One potential approach would be to follow the advice given in the TreeMap documentation:

Note that this implementation is not synchronized. If multiple threads access a map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with an existing key is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedSortedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:

SortedMap m = Collections.synchronizedSortedMap(new TreeMap(...));

I get the impression that the authors of the code hoped to avoid the need for explicit synchronization by forcing all write operations to execute in a single thread...but, as noted in the javadoc excerpt above, that's not good enough.

I have been able to work around this by going back to a copy of the plugins & Jenkins version I had at the beginning of March before the problem started for me in April.

The versions without this issue appear to be (at least in my case):

• Jenkins 2.161
• Pipeline: Basic Steps 2.14
• Pipeline: Build Step 2.7
• Pipeline: Groovy 2.63
• Pipeline: Nodes and Processes 2.29

Yes, there are sec vulnerabilities raised for both the Jenkins version & the plugins, but having random build failures which aren't project related undermines CI/CD ...

I was running Jenkins 2.164 & attempting to use Pipeline: Groovy 2.62 -> 2.67 and all of them appeared to have the same issue, so the 'problem' itself might not be within the workflow cps plugin & it might be in another supporting Pipeline plugin or Jenkins itself, but I can't test all the combinations to find out.

I just created this PR: https://github.com/jenkinsci/workflow-cps-plugin/pull/287.

As noted in the PR summary, I haven't done any testing to confirm that this fixes the issue – or, for that matter, to definitively identify the root cause. But that change does partially address some glaring thread-safety issues, so hopefully it will get picked up.

(and as to nullify005's experiences with different version combinations: as you say, perhaps the root cause lies in another component altogether, but OTOH, if the issue is indeed non-threadsafe manipulation of a collection, such bugs can often manifest in ways that are surprisingly subtle – and, in some cases, the particular manifestation can be affected by apparently unrelated changes)

Thanks everyone for the detailed investigation! From what I can tell it looks like the root cause is that steps using the new GeneralNonBlockingStepExecution API (JENKINS-49337) introduced in Pipeline: Step API 2.18 that interact with StepContext inside of their completion callback will do so not on the CPS VM thread, leading to the unsafe access of the TreeMap and the reported issue.

I'll take a look at the submitted PR. It looks ok to me at a glance, although I wonder if there could be other problems with running the completion callback in {{GeneralNonBlockingStepExecution }} on a separate thread (maybe we need to fix that instead of just making the collection thread safe), and I'm not sure if it fixes the reported issue. If anyone seeing the issue has a Jenkins instance on which you are comfortable testing pre-release plugins and are able to consistently reproduce the issue, feel free to install the .hpi file here which is a build of the plugin that includes that that PR and let us know whether it seems to help or not.

If anyone has a standalone (ideally minimal) Pipeline that reproduces the issue somewhat consistently I would be interested to see it so that we can test the proposed fix. I tried to reproduce the problem in a test but was only able to reproduce JENKINS-50474.

Jenkins: 2.164.2
Pipeline: Basic Steps 2.15
Pipeline: Build Step 2.9
Pipeline: Groovy 2.67
Pipeline: Nodes and Processes 2.30

I am seeing this also:

java.io.IOException: cannot find current thread
at org.jenkinsci.plugins.workflow.cps.CpsStepContext.doGet(CpsStepContext.java:300)
at org.jenkinsci.plugins.workflow.cps.CpsBodySubContext.doGet(CpsBodySubContext.java:88)
at org.jenkinsci.plugins.workflow.support.DefaultStepContext.get(DefaultStepContext.java:67)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Callback.finished(BindingStep.java:254)
at org.jenkinsci.plugins.credentialsbinding.impl.BindingStep$Execution2$Callback2.finished(BindingStep.java:162)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution$TailCall.lambda$onSuccess$0(GeneralNonBlockingStepExecution.java:140)
at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

I wonder if there could be other problems with running the completion callback in GeneralNonBlockingStepExecution on a separate thread (maybe we need to fix that instead of just making the collection thread safe)

Long before this API was introduced, steps were sometimes calling StepContext.get from arbitrary threads, whether that happened to be part of callback processing or not. (simple example) It is expected to be thread-safe.

A potential fix for this issue was just released in version 2.69 of Pipeline Groovy Plugin. I was never able to reproduce the issue in a test, so there is a possibility that it is still not fixed, so if you still see the issue in version 2.69 please reopen the ticket and include the stack trace you are getting.

dnusbaum thanks for the fix  I did update 2 days ago to Pipeline Groovy Plugin 2.69, and it looks that exception disappeared. Before upgrade I saw exception at least 2 times a day, after updating, not once (Jenkins LTS 2.164.3).

FWIW, I found a possibly-related crash that turned out to be in my own code. I was using a groovy `Map` that was modified by multiple closures run within a `parallel` step. This caused similar exceptions as well as odd incorrect map entries etc.

So keep an eye out for that. Posting here for people who see this later.

ringerc that ought to be safe, since the CPS VM runs green threads, and in no event should it cause an error like the one reported here which is below userspace. If you can reproduce such a problem, please file it separately.

I saw an instance of this error on the jenkins 2.414.2.  Anyone else?

Hello issue is still not resolved.
Jenkins Version 2.440.1

asenasw reopening an issue that has been closed for 3 months can be a help for Jenkins users, but it is much, much more helpful if you provide details about the failure that you are seeing.

Please provide the types of details that are described in "How to report an issue" so that others will be more interested to volunteer their time to investigate.

Without those details, others are unlikely to investigate any further.

Hello,
I am getting an issue when we are trying to run  

parallel couple of nodes(if the numbers is 4 it works) We are trying to run it with 10 and more.

I have examine your code :
workflow-cps-plugin/plugin/src/main/java/org/jenkinsci/plugins/workflow/cps/CpsStepContext.java at fbed9ac47728af09b7bd94d0197df1e5889139af · jenkinsci/workflow-cps-plugin (github.com)
For some reason this may  throw new IOException(e);
I tried to call get() with time delay and to create recursion but without result.

log.txt

asenasw you've not provided a Pipeline example that shows the problem. You've not provided the list of the specific plugin versions that you are using. Without those details, I doubt others will investigate further.

Hello this pipeline is dummy I can't upload our working project. I got the failure during the parallel buildMap
nodes fail at installation stage different node every time.

I have also attachedinstalledPlugins.txt the plugins we are using

i also encounter the same issue with 2.426.2 and plugins list

  "Office-365-Connector": "4.21.0",
  "active-directory": "2.35",
  "allure-jenkins-plugin": "2.31.1",
  "ansicolor": "1.0.4",
  "ant": "497.v94e7d9fffa_b_9",
  "antisamy-markup-formatter": "162.v0e6ec0fcfcf6",
  "apache-httpcomponents-client-4-api": "4.5.14-208.v438351942757",
  "artifactory": "4.0.6",
  "atlassian-jira-software-cloud": "2.0.13",
  "audit-trail": "361.v82cde86c784e",
  "authentication-tokens": "1.53.v1c90fd9191a_b_",
  "azure-ad": "471.vdfa_2441c67a_f",
  "azure-commons": "1.1.3",
  "azure-credentials": "312.v0f3973cd1e59",
  "azure-sdk": "157.v855da_0b_eb_dc2",
  "azure-vm-agents": "901.ved986df424b_3",
  "badge": "1.9.1",
  "basic-branch-build-strategies": "81.v05e333931c7d",
  "bitbucket": "241.v6d24a_57f9359",
  "blueocean": "1.27.11",
  "blueocean-autofavorite": "1.2.5",
  "blueocean-bitbucket-pipeline": "1.27.11",
  "blueocean-commons": "1.27.11",
  "blueocean-config": "1.27.11",
  "blueocean-core-js": "1.27.11",
  "blueocean-dashboard": "1.27.11",
  "blueocean-display-url": "2.4.2",
  "blueocean-events": "1.27.11",
  "blueocean-git-pipeline": "1.27.11",
  "blueocean-github-pipeline": "1.27.11",
  "blueocean-i18n": "1.27.11",
  "blueocean-jira": "1.27.11",
  "blueocean-jwt": "1.27.11",
  "blueocean-personalization": "1.27.11",
  "blueocean-pipeline-api-impl": "1.27.11",
  "blueocean-pipeline-editor": "1.27.11",
  "blueocean-pipeline-scm-api": "1.27.11",
  "blueocean-rest": "1.27.11",
  "blueocean-rest-impl": "1.27.11",
  "blueocean-web": "1.27.11",
  "bootstrap5-api": "5.3.2-3",
  "bouncycastle-api": "2.30.1.77-225.v26ea_c9455fd9",
  "branch-api": "2.1152.v6f101e97dd77",
  "build-name-setter": "2.4.2",
  "build-timeout": "1.32",
  "build-token-root": "151.va_e52fe3215fc",
  "build-token-trigger": "1.0.0",
  "build-user-vars-plugin": "1.9",
  "built-on-column": "1.4",
  "caffeine-api": "3.1.8-133.v17b_1ff2e0599",
  "change-assembly-version-plugin": "1.10",
  "checks-api": "2.0.2",
  "cloud-stats": "336.v788e4055508b_",
  "cloudbees-bitbucket-branch-source": "883.v041fa_695e9c2",
  "cloudbees-folder": "6.858.v898218f3609d",
  "cobertura": "1.17",
  "code-coverage-api": "4.99.0",
  "codeql": "1.0",
  "command-launcher": "107.v773860566e2e",
  "commons-httpclient3-api": "3.1-3",
  "commons-lang3-api": "3.13.0-62.v7d18e55f51e2",
  "commons-text-api": "1.11.0-95.v22a_d30ee5d36",
  "conditional-buildstep": "1.4.3",
  "config-file-provider": "968.ve1ca_eb_913f8c",
  "configuration-as-code": "1775.v810dc950b_514",
  "copyartifact": "722.v0662a_9b_e22a_c",
  "coverage": "1.10.0",
  "credentials": "1319.v7eb_51b_3a_c97b_",
  "credentials-binding": "657.v2b_19db_7d6e6d",
  "custom-checkbox-parameter": "1.4",
  "cvs": "2.19.1",
  "dashboard-view": "2.508.va_74654f026d1",
  "data-tables-api": "1.13.8-3",
  "disable-github-multibranch-status": "1.2",
  "display-url-api": "2.200.vb_9327d658781",
  "docker-commons": "439.va_3cb_0a_6a_fb_29",
  "docker-workflow": "572.v950f58993843",
  "dtkit-api": "3.0.2",
  "durable-task": "550.v0930093c4b_a_6",
  "echarts-api": "5.4.3-3",
  "editable-choice": "71.v02a291ebbe45",
  "email-ext": "2.105",
  "embeddable-build-status": "467.v4a_954796e45d",
  "envinject": "2.908.v66a_774b_31d93",
  "envinject-api": "1.199.v3ce31253ed13",
  "extended-choice-parameter": "381.v360a_25ea_017c",
  "extended-read-permission": "53.v6499940139e5",
  "external-monitor-job": "215.v2e88e894db_f8",
  "favorite": "2.208.v91d65b_7792a_c",
  "file-parameters": "316.va_83a_1221db_a_7",
  "flexible-publish": "0.16.1",
  "font-awesome-api": "6.5.1-2",
  "forensics-api": "2.3.0",
  "git": "5.2.1",
  "git-changelog": "3.38",
  "git-client": "4.7.0",
  "git-server": "114.v068a_c7cc2574",
  "github": "1.38.0",
  "github-api": "1.318-461.v7a_c09c9fa_d63",
  "github-branch-source": "1785.v99802b_69816c",
  "github-pullrequest": "0.7.0",
  "global-slack-notifier": "1.5",
  "google-oauth-plugin": "1.330.vf5e86021cb_ec",
  "google-play-android-publisher": "4.2",
  "gradle": "2.10",
  "groovy": "457.v99900cb_85593",
  "gson-api": "2.10.1-15.v0d99f670e0a_7",
  "h2-api": "11.1.4.199-12.v9f4244395f7a_",
  "handy-uri-templates-2-api": "2.1.8-30.v7e777411b_148",
  "hidden-parameter": "237.v4b_df26c7a_f0e",
  "htmlpublisher": "1.33",
  "http_request": "1.18",
  "instance-identity": "185.v303dc7c645f9",
  "ionicons-api": "70.v2959a_b_74e3cf",
  "ivy": "2.5",
  "jackson2-api": "2.17.0-379.v02de8ec9f64c",
  "jakarta-activation-api": "2.1.3-1",
  "jakarta-mail-api": "2.1.3-1",
  "javadoc": "243.vb_b_503b_b_45537",
  "javax-activation-api": "1.2.0-6",
  "javax-mail-api": "1.6.2-9",
  "jaxb": "2.3.9-1",
  "jdk-tool": "73.vddf737284550",
  "jenkins-design-language": "1.27.11",
  "jenkins-jira-issue-updater": "1.18",
  "jenkins-jira-plugin": "3.4.0",
  "jersey2-api": "2.42-147.va_28a_44603b_d5",
  "jira": "3.13",
  "jira-steps": "2.0.165.v8846cf59f3db",
  "jira-trigger": "1.0.3",
  "jjwt-api": "0.11.5-112.ve82dfb_224b_a_d",
  "jnr-posix-api": "3.1.19-1",
  "job-dsl": "1.87",
  "jobConfigHistory": "1229.v3039470161a_d",
  "joda-time-api": "2.12.7-29.v5a_b_e3a_82269a_",
  "jquery": "1.12.4-1",
  "jquery3-api": "3.7.1-1",
  "jsch": "0.2.16-86.v42e010d9484b_",
  "json-api": "20240303-41.v94e11e6de726",
  "json-path-api": "2.9.0-33.v2527142f2e1d",
  "junit": "1265.v65b_14fa_f12f0",
  "kubernetes": "4186.v1d804571d5d4",
  "kubernetes-client-api": "6.10.0-240.v57880ce8b_0b_2",
  "kubernetes-credentials": "0.11",
  "ldap": "719.vcb_d039b_77d0d",
  "leastload": "3.0.0",
  "lockable-resources": "1245.vb_05f8a_4e28db_",
  "logstash": "2.5.0218.v0a_ff8fefc12b_",
  "mailer": "470.vc91f60c5d8e2",
  "mapdb-api": "1.0.9-40.v58107308b_7a_7",
  "mask-passwords": "173.v6a_077a_291eb_5",
  "matrix-auth": "3.2.2",
  "matrix-project": "822.824.v14451b_c0fd42",
  "maven-plugin": "3.23",
  "mercurial": "1260.vdfb_723cdcc81",
  "metrics": "4.2.21-449.v6960d7c54c69",
  "mina-sshd-api-common": "2.12.1-101.v85b_e08b_780dd",
  "mina-sshd-api-core": "2.12.1-101.v85b_e08b_780dd",
  "monitoring": "1.98.0",
  "msbuild": "1.31",
  "mstest": "1.0.5",
  "multibranch-action-triggers": "1.8.6",
  "naginator": "1.436.vb_e769dcb_cdf6",
  "nant": "248.vcc8a_3eec8db_a",
  "new-relic": "1.0.4",
  "next-build-number": "1.8",
  "nodelabelparameter": "1.12.0",
  "nunit": "465.v0324954b_2990",
  "oauth-credentials": "0.646.v02b_66dc03d2e",
  "okhttp-api": "4.11.0-172.vda_da_1feeb_c6e",
  "opentelemetry": "3.1138.v80fc844ed246",
  "pagerduty": "0.7.1",
  "pam-auth": "1.10",
  "parameter-separator": "129.v86b_98b_cb_5274",
  "parameterized-trigger": "787.v665fcf2a_830b_",
  "performance": "957.v658a_7065b_92a_",
  "pipeline-build-step": "540.vb_e8849e1a_b_d8",
  "pipeline-github": "2.8-159.09e4403bc62f",
  "pipeline-github-lib": "42.v0739460cda_c4",
  "pipeline-graph-analysis": "216.vfd8b_ece330ca_",
  "pipeline-groovy-lib": "704.vc58b_8890a_384",
  "pipeline-input-step": "477.v339683a_8d55e",
  "pipeline-maven": "1396.veb_f07b_2fc1d8",
  "pipeline-maven-api": "1396.veb_f07b_2fc1d8",
  "pipeline-milestone-step": "119.vdfdc43fc3b_9a_",
  "pipeline-model-api": "2.2184.v0b_358b_953e69",
  "pipeline-model-definition": "2.2184.v0b_358b_953e69",
  "pipeline-model-extensions": "2.2184.v0b_358b_953e69",
  "pipeline-rest-api": "2.34",
  "pipeline-stage-step": "312.v8cd10304c27a_",
  "pipeline-stage-tags-metadata": "2.2184.v0b_358b_953e69",
  "pipeline-stage-view": "2.34",
  "pipeline-utility-steps": "2.16.2",
  "plain-credentials": "179.vc5cb_98f6db_38",
  "plot": "2.1.12",
  "plugin-usage-plugin": "4.4",
  "plugin-util-api": "3.8.0",
  "postbuildscript": "3.2.0-550.v88192b_d3e922",
  "powershell": "2.1",
  "prism-api": "1.29.0-11",
  "publish-over": "0.22",
  "publish-over-ftp": "1.17",
  "pubsub-light": "1.18",
  "rapid7-insightvm-container-assessment": "1.0.21",
  "rebuild": "332.va_1ee476d8f6d",
  "release-helper": "1.3.3",
  "resource-disposer": "0.23",
  "robot": "3.5.1",
  "run-condition": "1.7",
  "scm-api": "683.vb_16722fb_b_80b_",
  "scoverage": "1.4.0",
  "script-security": "1326.vdb_c154de8669",
  "skip-notifications-trait": "313.vd1337c8f8134",
  "slack": "684.v833089650554",
  "snakeyaml-api": "2.2-111.vc6598e30cc65",
  "snyk-security-scanner": "4.0.2",
  "sonar": "2.17.2",
  "sse-gateway": "1.26",
  "ssh-agent": "346.vda_a_c4f2c8e50",
  "ssh-credentials": "337.v395d2403ccd4",
  "ssh-slaves": "2.948.vb_8050d697fec",
  "sshd": "3.322.v159e91f6a_550",
  "structs": "337.v1b_04ea_4df7c8",
  "subversion": "1256.vee91953217b_6",
  "test-results-analyzer": "0.4.1",
  "test-stability": "2.3",
  "thinBackup": "1.19",
  "throttle-concurrents": "2.14",
  "timestamper": "1.26",
  "token-macro": "400.v35420b_922dcb_",
  "trilead-api": "2.142.v748523a_76693",
  "uno-choice": "2.8.3",
  "variant": "60.v7290fc0eb_b_cd",
  "veracode-scan": "24.2.23.0",
  "versioncolumn": "233.v2d198f8212a_2",
  "view-job-filters": "369.ve0513a_a_f5524",
  "vstestrunner": "1.0.8",
  "windows-azure-storage": "1.1.6",
  "workflow-aggregator": "596.v8c21c963d92d",
  "workflow-api": "1291.v51fd2a_625da_7",
  "workflow-basic-steps": "1049.v257a_e6b_30fb_d",
  "workflow-cps": "3894.vd0f0248b_a_fc4",
  "workflow-durable-task-step": "1331.vc8c2fed35334",
  "workflow-job": "1385.vb_58b_86ea_fff1",
  "workflow-multibranch": "773.vc4fe1378f1d5",
  "workflow-scm-step": "427.v4ca_6512e7df1",
  "workflow-step-api": "657.v03b_e8115821b_",
  "workflow-support": "896.v175a_a_9c5b_78f",
  "ws-cleanup": "0.45",
  "xunit": "3.1.4" 

dummy code is attached, please help check, thanks. 

I would like to add I am also experiencing this Jenkins 2.440.1.  I also find at times the pipeline doesn't throw an error but will stop logging to console and sit there indefinitely. 

Just to add to my comments, I run another step with the below conditionals in parallel failing step which looks like this:

when {
        anyOf {
          allOf {
            changeRequest()
            changeset "file.props"
          }
          environment name: 'DEPENDENCIES', value: 'true'
        }
      } 

The step where the issue occurs has this in the console log which is odd

hudson.plugins.git.GitChangeSetList

I can see posts above have an object being written to console also.

The stack trace in the build has (note NotSerializableException as seen in other comments)

10:04:27  an exception which occurred:
10:04:27  	in field com.cloudbees.groovy.cps.impl.BlockScopeEnv.locals
10:04:27  	in object com.cloudbees.groovy.cps.impl.BlockScopeEnv@1ba97cad
10:04:27  	in field com.cloudbees.groovy.cps.impl.CallEnv.caller
.........
10:04:27  Also:   org.jenkinsci.plugins.workflow.actions.ErrorAction$ErrorId: 8f10b5df-578b-4c09-b64d-05287fa62931
10:04:27  Caused: java.io.NotSerializableException: hudson.plugins.git.GitChangeSetList
10:04:27  	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:278) 

I am testing by removing the changeset conditional however for me this issue occurs sporadically so I will have to test this over a week.

This has just become a collection of probably unrelated issues that happen to have a similar symptom. If you can reproduce a problem of this type from scratch please file a separate issue (and link it). The cause and possible fix may be distinct in each case; for example cj_au’s issue sounds like it could be some fully reproducible mistake in pipeline-model-definition-plugin.