Actually it's both not cosmetic (the node will accept a second task) and not a bug (documented to behave this way).
Two issues:
- Your API doesn't show anything relevant. The second executor will be removed once the task is finished, numExecutors is already 1 before.
- I've been unable to reproduce the issue if the task executes on the first executor 'executor #0' (see also /threadDump), only if it's a higher index. Hence the recent questions.
To clarify, what happens is that every executor has an index from 0...N-1 with N being numExecutors. When reducing the number to M, Jenkins fills up executors 0...M-1, killing all idle ones, and leaving building ones alone. On a five executor node (0...4) with #3 building, setting numExecutors to 2 will result in #0, #1, and #3 existing at first, and #3 removed once the task is finished. This is not reflected on the UI, those indexes are different from the internal ones.
I'm investigating whether the number of busy executors could be considered when reducing, e.g. reusing the example above, set numExecutors to 2 will result in #0 and #3, and once #3 is finished it'll be killed but a new #1 created.
Which executor (number) is the job running on, before and after you reduce the number of executors?