The concurrent.futures.ThreadPoolExecutor class, which is the default asyncio executor, introduced the _idle_semaphore field in version 3.8 in order to track idle threads so they can be reused before increasing the pool size unnecessarily.
This semaphore counter becomes unbalanced when the thread pool is over-saturated, as can be seen in the file provided. This is due to workers always incrementing the count after finishing a job, whereas the executor only decrements the count if it is already greater than 0.
This seems to be a logic bug unrelated to the running environment and introduced since python 3.8.

To be clear, this probably doesn't have any actual consequence, since the right number of threads is launched anyway (at least in the example). But it's probably worth making the implementation less quirky (also, the semaphore's internal counter *might* overflow at some point?).

I was trying to instrument one of our executors to expose some metrics, so I tried using the value of the semaphore as the number of idle threads and I noticed it was way too large. If this was fixed getting these metrics would be easier.