[Bug]: maxWorkers is always 1 for some linux systems and node v22.12.0 (current LTS)

[rlindner81]

Version

29.7.0

Steps to reproduce

I encountered this on a cluster of CI servers, when upgrading from node v20 to v22.12.0.

The server has a 32 core cpu lscpu output:

Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        48 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               32
On-line CPU(s) list:                  0-31
Vendor ID:                            AuthenticAMD
Model name:                           AMD EPYC 7B13
CPU family:                           25
Model:                                1
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            2
Stepping:                             0
BogoMIPS:                             4900.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext invpcid_single ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save umip vaes vpclmulqdq rdpid fsrm
Hypervisor vendor:                    KVM
Virtualization type:                  full
L1d cache:                            512 KiB (16 instances)
L1i cache:                            512 KiB (16 instances)
L2 cache:                             8 MiB (16 instances)
L3 cache:                             64 MiB (2 instances)
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-7,16-23
NUMA node1 CPU(s):                    8-15,24-31
Vulnerability Gather data sampling:   Not affected
Vulnerability Itlb multihit:          Not affected
Vulnerability L1tf:                   Not affected
Vulnerability Mds:                    Not affected
Vulnerability Meltdown:               Not affected
Vulnerability Mmio stale data:        Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed:               Not affected
Vulnerability Spec rstack overflow:   Mitigation; safe RET
Vulnerability Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:             Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                  Not affected
Vulnerability Tsx async abort:        Not affected

What I found was that jest always used maxWorkers: 1. You could see this, with

npx jest --showConfig | jq '.globalConfig.maxWorkers' 

Looking at the coding, I recreated the problem with this script which also reported one on the machine.

function _os() {
  const data = require("os");
  _os = function () {
    return data;
  };
  return data;
}

function getNumCpus() {
  return typeof _os().availableParallelism === "function"
    ? (0, _os().availableParallelism)()
    : ((0, _os().cpus)()?.length ?? 1);
}

console.log("jest numcpus:", getNumCpus());

In other words, the availableParallelism implementation seems to be overzealous for recent node versions and may not be viable to use in this context.

I created a monkey-patch and this resolved the problem for me.

function getNumCpus() {
  return (0, _os().cpus)()?.length ?? 1;
}

Expected behavior

maxWorkers should reflect the number of available CPUs, or if relative values are configured a fraction of the number of CPUs.

Actual behavior

Instead, in the described constellation, it was always one.

Additional context

No response

Environment

See above

[rlindner81]

It would be fair to argue this is a nodejs problem and not a jest problem. I opened it here, not just to report, but also for others to find when they run into this issue.