Quite a number of different manifestations of this observed by a number of our customers using different cloud providers. In common is the use of a "single-shot" style retention strategy, though the root cause is observable with great care when using any retention strategy other than Always.

The basic issue is that you cannot determine if a node is idle unless you hold the Queue lock as that is the only way to ensure that the Queue is not in the process of assigning work to the node you are removing.

Symptoms include:

• Build logs that claim the job was executed on "master" even though the job is tied to a specific label that master does not have. The build log will have been "unable to be determined"

• Build logs where the node is gone just as soon as the job starts

  2015-03-05 13:27:55.101 Started by upstream project "____" build number ___ 
  2015-03-05 13:27:55.102 originally caused by: 
  2015-03-05 13:27:55.103 Started by user ____ 
  2015-03-05 13:27:55.437 FATAL: no longer a configured node for ____ 
  2015-03-05 13:27:55.440 java.lang.IllegalStateException: no longer a configured node for ____ 
  2015-03-05 13:27:55.440 at hudson.model.AbstractBuild$AbstractBuildExecution.getCurrentNode(AbstractBuild.java:452) 
  2015-03-05 13:27:55.440 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:484) 
  2015-03-05 13:27:55.441 at hudson.model.Run.execute(Run.java:1745) 
  2015-03-05 13:27:55.441 at hudson.model.Build.run(Build.java:113) 
  2015-03-05 13:27:55.441 at hudson.model.ResourceController.execute(ResourceController.java:89) 
  2015-03-05 13:27:55.441 at hudson.model.Executor.run(Executor.java:240)