[JENKINS-40307] Not passing threshold to ReverseBuildTrigger in Pipeline leads to NPEs

[jenkins-infra-bot]

When setting up dependencies in a multibranch pipeline, I wrote

properties([
pipelineTriggers([upstream(upstreamProjects: dependencies.join(','))])
    ])

I had omitted the threshold parameter, assuming that it would default to SUCCESS (and I wasn't sure what to put in anyway due to JENKINS-40304). The dependencies weren't working. I discovered this NPE in the logs:

Dec 08, 2016 11:08:34 AM hudson.model.listeners.RunListener report
WARNING: RunListener failed
java.lang.NullPointerException
at hudson.model.Result.isBetterOrEqualTo(Result.java:130)
at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:138)
at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:88)
at jenkins.triggers.ReverseBuildTrigger$RunListenerImpl.onCompleted(ReverseBuildTrigger.java:258)
at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:202)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.finish(WorkflowRun.java:582)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$1200(WorkflowRun.java:120)
at org.jenkinsci.plugins.workflow.job.WorkflowRun$GraphL.onNewHead(WorkflowRun.java:865)
at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.notifyListeners(CpsFlowExecution.java:1081)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$3.run(CpsThreadGroup.java:398)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:35)
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(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

From what I can tell, omitting the threshold parameter is causing it to be set to null, leading to the null pointer exception. View Configuration in the GUI didn't reveal any problems, instead showing the threshold as success.

I don't know if there is any way in the Jenkins reflection system to prevent this, but it would be nice if it was possible for the pipeline script to give an error rather than silently inserting properties that cause exceptions, or else to pick a sensible default.

---

Originally reported by bmerry, imported from: Not passing threshold to ReverseBuildTrigger in Pipeline leads to NPEs

• status: Open
• priority: Minor
• component(s): core
• label(s): newbie-friendly, pipeline, robustness
• resolution: Unresolved
• votes: 1
• watchers: 2
• imported: 2025-11-24

Raw content of original issue

When setting up dependencies in a multibranch pipeline, I wrote

properties([
        pipelineTriggers([upstream(upstreamProjects: dependencies.join(','))])
    ])


I had omitted the threshold parameter, assuming that it would default to SUCCESS (and I wasn't sure what to put in anyway due to JENKINS-40304). The dependencies weren't working. I discovered this NPE in the logs:

Dec 08, 2016 11:08:34 AM hudson.model.listeners.RunListener report
WARNING: RunListener failed
java.lang.NullPointerException
        at hudson.model.Result.isBetterOrEqualTo(Result.java:130)
        at jenkins.triggers.ReverseBuildTrigger.shouldTrigger(ReverseBuildTrigger.java:138)
        at jenkins.triggers.ReverseBuildTrigger.access$000(ReverseBuildTrigger.java:88)
        at jenkins.triggers.ReverseBuildTrigger$RunListenerImpl.onCompleted(ReverseBuildTrigger.java:258)
        at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:202)
        at org.jenkinsci.plugins.workflow.job.WorkflowRun.finish(WorkflowRun.java:582)
        at org.jenkinsci.plugins.workflow.job.WorkflowRun.access$1200(WorkflowRun.java:120)
        at org.jenkinsci.plugins.workflow.job.WorkflowRun$GraphL.onNewHead(WorkflowRun.java:865)
        at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.notifyListeners(CpsFlowExecution.java:1081)
        at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$3.run(CpsThreadGroup.java:398)
        at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:35)
        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(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)


From what I can tell, omitting the threshold parameter is causing it to be set to null, leading to the null pointer exception. View Configuration in the GUI didn't reveal any problems, instead showing the threshold as success.
I don't know if there is any way in the Jenkins reflection system to prevent this, but it would be nice if it was possible for the pipeline script to give an error rather than silently inserting properties that cause exceptions, or else to pick a sensible default.

environment

Jenkins 2.7.1 (Docker image)<br/>
workflow-job-plugin 2.9.2

[jenkins-infra-bot]

bmerry:

• Original comment link
• Raw content of original comment:

  For anyone arriving here from a search: I found the following script (run in the script console) useful to identify the jobs that had null thresholds:
  
  for (item in Jenkins.instance.allItems) {
    for (entry in item.properties) {
      def value
      try
      {
        value = entry.value;
      }
      catch (IllegalPropertyError) {
        continue;
      }
      if (value instanceof org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty) {
        for (trigger in value.triggers) {
          if (trigger instanceof jenkins.triggers.ReverseBuildTrigger)
            println(item.fullName + " " + trigger.threshold)
        }
      }
    }
  }
  
  
  

For anyone arriving here from a search: I found the following script (run in the script console) useful to identify the jobs that had null thresholds:

for (item in Jenkins.instance.allItems) {
  for (entry in item.properties) {
    def value
    try
    {
      value = entry.value;
    }
    catch (IllegalPropertyError) {
      continue;
    }
    if (value instanceof org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty) {
      for (trigger in value.triggers) {
if (trigger instanceof jenkins.triggers.ReverseBuildTrigger)
  println(item.fullName + " " + trigger.threshold)
      }
    }
  }
}

[MarkEWaite]

I'm unable to duplicate the issue as described, but the description aligns with pull request:

• Fix NPE in ReverseBuildTrigger due to null upstream threshold #23916

Resolving this as a duplicate of issue:

• [JENKINS-39044] NPE thrown when firing upstream jobs #17611

Fixed in Jenkins 2.542 released 16 Dec 2025.