Field note /
Reading a thread cap as the container's CPU count
Filing Harbor's Jenkins worker check read a per-process thread limit as the number of CPUs the test container had. Targeted checks separated that from the test failures.
How the finding changed
Belief
Running GNU nproc inside the test container would report how many CPUs were available for pytest-xdist workers (pytest-xdist runs tests in parallel).
Evidence
The executor and container allowed 56 CPUs, but nproc returned 1 while OMP_NUM_THREADS was set to 1 to limit threads inside each worker.
Contradiction
With the OpenMP variables cleared for the probe only, nproc reported 56. The 1 came from the thread limit and not from a container CPU quota. Separately, the failing Python suite had stale synthetic fixtures and assertions.
Correction
Probe the CPU count with the thread limit cleared in a subshell only, keep single-thread math libraries inside the pytest workers, and cap the worker count at what the probe reports. Update the stale synthetic fixtures without relaxing how unknown and false tax evidence are told apart.
Current claim boundary
Source fixes for worker detection and fixtures are merged, and reviewer and operator reports support the targeted checks. A complete green post-merge Jenkins run, a measured speedup and a production deployment have not been established.
Evidence
Curated from internal source and limited Jenkins observations. Host logs and the access-controlled application repository are not public. Reported targeted tests are not full CI acceptance.