[JENKINS-57507] Parameterized Trigger node label can get stuck

If Build A is set up to trigger a project using "Build On Same Node", and the machine running Build A disconnects from Jenkins (crash, network issue, reboot, etc.), what happens is that Build B is queued with the appropriate label (say "build-7").

 

Jenkins then cleans up the Label "build-7", because there are no machines with that label.  The machine reconnects, causing Jenkins to create a new Label "build-7".  However, the old Label instance representing the same label string (attached to the NodeAction in the plugin) is no longer referenced by Jenkins and can't be refreshed.

 

The result is that the build waiting to build on "build-7" waits in the queue forever, even though the targeted machine is connected and live.  The expected behavior is that if a machine with a matching node label is live, the build should start.

 

A workaround, today, is to go into the Script Console and manually kick the orphaned label, upon which the orphaned build will start immediately.  Example:

 

Jenkins.getInstance().getQueue().buildables[0].getAssignedLabel().reset() 

 

 

---
Originally reported by elliot_nelson, imported from: Parameterized Trigger node label can get stuck

• status: Open
  
• priority: Minor
  
• component(s): parameterized-trigger-plugin
  
• label(s): parameterized-trigger, plugin, slave
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 2025-12-07
  

Raw content of original issue

If Build A is set up to trigger a project using "Build On Same Node", and the machine running Build A disconnects from Jenkins (crash, network issue, reboot, etc.), what happens is that Build B is queued with the appropriate label (say "build-7").


 


Jenkins then cleans up the Label "build-7", because there are no machines with that label.  The machine reconnects, causing Jenkins to create a new Label "build-7".  However, the old Label instance representing the same label string (attached to the NodeAction in the plugin) is no longer referenced by Jenkins and can't be refreshed.


 


The result is that the build waiting to build on "build-7" waits in the queue forever, even though the targeted machine is connected and live.  The expected behavior is that if a machine with a matching node label is live, the build should start.


 


A workaround, today, is to go into the Script Console and manually kick the orphaned label, upon which the orphaned build will start immediately.  Example:


 



Jenkins.getInstance().getQueue().buildables[0].getAssignedLabel().reset() 



 


 

• environment: Jenkins 2.138.2, Plugin 2.35.2, Java 1.8.x, Linux