One of our artists has added a bunch of machines to the blacklist of a job, and despite that, within a minute, one of those blacklisted machines picked up the task anyway:
[attachment=0]Capture.PNG[/attachment]
Any ideas why?
cheers
laszlo
Huh, interesting. At first I thought it might’ve been close enough in time that there was still a cached value, or clock drift in the timestamps or somesuch.
But it clearly picked up on the blacklist change, it mentions in the log that the Limit Stub it currently held for that job was invalidated (due to the holder being added to the blacklist – I believe the log actually claims '‘whitelist’ but that’s just a typo).
I’d suspect it’s a bug in our dequeuing code that’s not acknowledging that properly, we’ll have a bit of a deeper look at this.
Annoying obvious question time: is it possible that the machine list was actually set as a whitelist? Can you provide a full slave log from when this occurred? Also, is this something you see happen regularly or was this a one off?
The job, and the slave logs are long gone since.
But i checked and double checked at the time, and the job history did not indicate any changes to the whitelist/blacklist, other than the one time assignment which the screenshot shows. There were no other job property adjustments in the history.
I noticed an odd message in the slave log in this screenshot:
“Limit stub for ‘’ (held by ‘lapro3329’) is no longer valid, the holder has been added to…”
immediately before dequeuing the task for that very job: “Successfully dequeued 1 task(s). Returning.”
Sadly the message is cut off there, but i suspect its about the blacklist?