Review requested:

• @nodejs/security-wg

CI: https://ci.nodejs.org/job/node-test-pull-request/65574/

CI: https://ci.nodejs.org/job/node-test-pull-request/65590/

This still has the same CI failures as #56616 (comment). Most likely this version of libuv has broken something on 32-bit Windows. We no longer build on 32-bit Windows for Node.js 23 which is why this would not have been noticed until attempting to land on Node.js 22 (where we still test and release on 32-bit Windows).

cc @nodejs/libuv @nodejs/platform-windows

I only see this error. Are there more?

  + 'ERR_FS_EISDIR'
  - 'ERR_FS_CP_EINVAL'

That's node's wrapper around uv_fs_copyfile(), right? The new error code seems more appropriate, doesn't it?

On 32-bit Windows, the error is:

> python tools\test.py --mode=release  --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel 
Can't determine the arch of: 'C:\workspace\node-test-binary-windows-js-suites\node\Release\node.exe'

Coming from

I'll spin a VM and inspect. Please do not expect anything, I do this on my spare time

Can anyone from @nodejs/build help me out setting up the box? I haven't be able to setup visual studio, not even with Boxstarter. Apparently 32bits vs stuff is not longer distributed or something.

Refs: https://github.com/nodejs/node/blob/main/BUILDING.md#option-3-automated-install-with-boxstarter

Cc @nodejs/platform-windows

Most likely this version of libuv has broken something on 32-bit Windows.

Not quite sure, libuv has jobs for Win32¹; any idea about how should I debug this one?

On 32-bit Windows, the error is:

> python tools\test.py --mode=release  --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel 
Can't determine the arch of: 'C:\workspace\node-test-binary-windows-js-suites\node\Release\node.exe'

Coming from

node/tools/test.py

Lines 1708 to 1713 in 2a6f908

	archEngineContext = Execute([vm, "-p", "process.arch"], context)
	vmArch = archEngineContext.stdout.rstrip()
	if archEngineContext.exit_code != 0 or vmArch == "undefined":
	print("Can't determine the arch of: '%s'" % vm)
	print(archEngineContext.stderr.rstrip())
	continue

FWIW I downloaded binary.tgz from https://ci.nodejs.org/job/node-compile-windows/60791/nodes=win-vs2022-x86/ (from https://ci.nodejs.org/job/node-test-pull-request/65590/). And running node -p process.arch gives ia32:

C:\Users\rlau\Downloads\test>node -p process.versions
{
  node: '22.14.1-pre',
  acorn: '8.14.0',
  ada: '2.9.2',
  amaro: '0.3.0',
  ares: '1.34.4',
  brotli: '1.1.0',
  cjs_module_lexer: '1.4.1',
  cldr: '46.0',
  icu: '76.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '10',
  nbytes: '0.1.1',
  ncrypto: '0.0.1',
  nghttp2: '1.64.0',
  nghttp3: '1.6.0',
  ngtcp2: '1.10.0',
  openssl: '3.0.15+quic',
  simdjson: '3.10.1',
  simdutf: '6.0.3',
  sqlite: '3.47.2',
  tz: '2024b',
  undici: '6.21.1',
  unicode: '16.0',
  uv: '1.50.0',
  uvwasi: '0.0.21',
  v8: '12.4.254.21-node.22',
  zlib: '1.3.0.1-motley-82a5fec'
}

C:\Users\rlau\Downloads\test>node -p process.arch
ia32

C:\Users\rlau\Downloads\test>

So maybe this is something more subtle affecting Node.js being executed by the Python-based test runner (either not capturing stdout or exiting with a non zero exit code)?

So maybe this is something more subtle affecting Node.js being executed by the Python-based test runner (either not capturing stdout or exiting with a non zero exit code)?

Maybe, I tried to move the "binary artifacts" into a fresh Node.js repo in my VM; tests are running "normally". It was as simple as copying the "binary/Release" folder and paste it into "node/out/"; tests seems ok

PS C:\Users\jj\Desktop\node> python tools\test.py --mode=release  --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel
Skipping pseudo-tty tests, as pseudo terminals are not available on Windows.
TAP version 13
1..1051
ok 1 async-hooks/test-embedder.api.async-resource.runInAsyncScope
  ---
  duration_ms: 54.00200
  ...
ok 2 async-hooks/test-async-local-storage-promises
  ---
  duration_ms: 63.30900
  ...
ok 3 async-hooks/test-async-local-storage-async-await
  ---
  duration_ms: 67.99700
  ...
ok 4 async-hooks/test-async-wrap-providers
  ---
  duration_ms: 76.53700
  ...
ok 5 async-hooks/test-async-local-storage-enter-with
  ---
  duration_ms: 80.59000
  ...
ok 6 async-hooks/test-async-local-storage-http
  ---
  duration_ms: 95.92200
  ...

Just FYI, I haven't been able to compile Node.js in that VM; that's why I'm using the artefacts.

Re-ran the the win job with a print of the command addition. https://ci.nodejs.org/job/node-test-commit-windows-fanned/69059/

Hi @juanarbol, just a FYI, I'll issue a v22 release soon this week, and this PR might not go due to red-CI.

Hi @juanarbol, just a FYI, I'll issue a v22 release soon this week, and this PR might not go due to red-CI.

I'm ok tho, I don't have the bandwidth to have a deadline or something; I'll keep working on this one on my spare time.