test: fix timeout in test-wasi-pthread for CI stability

[Ronitsabhaya75]

Summary

This PR fixes the root cause of the test-wasi-pthread flakiness by adding retry logic for resource exhaustion scenarios, rather than just increasing timeouts.

Problem

As identified by @joyeecheung, the issue was not timeouts but pthread_create returning errors due to resource constraints in CI environments
Assertion failed: r == 0 (c/pthread.c: main: 17)

Solution

1. C Code: Added retry logic with exponential backoff for pthread_create failures (EAGAIN/ENOMEM)
2. JavaScript: Added retry logic for Node.js Worker creation failures

[nodejs-github-bot]

Review requested:

• @nodejs/wasi

[joyeecheung]

The test was marked as flaky because it frequently timed out in CI environments

FWIW the failure was unrelated to timeouts, it was caused by pthread_create returning an error:

[process 1130254]: --- stderr ---
  (node:1130254) ExperimentalWarning: WASI is an experimental feature and might change at any time
  (Use `node --trace-warnings ...` to show where the warning was created)
  fd_write(2, 69600, 2, 69596)
  Assertion failed: r == 0 (c/pthread.c: main: 17)
  wasm://wasm/00020abe:1


  RuntimeError: unreachable
      at wasm://wasm/00020abe:wasm-function[26]:0x892
      at wasm://wasm/00020abe:wasm-function[27]:0x8da
      at wasm://wasm/00020abe:wasm-function[13]:0x46a
      at wasm://wasm/00020abe:wasm-function[11]:0x328
      at WASI.start (node:wasi:138:7)
      at /home/iojs/build/workspace/node-test-commit-arm/test/fixtures/wasi-preview-1.js:191:20

[Ronitsabhaya75]

The test was marked as flaky because it frequently timed out in CI environments

FWIW the failure was unrelated to timeouts, it was caused by pthread_create returning an error:

[process 1130254]: --- stderr ---
  (node:1130254) ExperimentalWarning: WASI is an experimental feature and might change at any time
  (Use `node --trace-warnings ...` to show where the warning was created)
  fd_write(2, 69600, 2, 69596)
  Assertion failed: r == 0 (c/pthread.c: main: 17)
  wasm://wasm/00020abe:1


  RuntimeError: unreachable
      at wasm://wasm/00020abe:wasm-function[26]:0x892
      at wasm://wasm/00020abe:wasm-function[27]:0x8da
      at wasm://wasm/00020abe:wasm-function[13]:0x46a
      at wasm://wasm/00020abe:wasm-function[11]:0x328
      at WASI.start (node:wasi:138:7)
      at /home/iojs/build/workspace/node-test-commit-arm/test/fixtures/wasi-preview-1.js:191:20

I thought it was time out my bad.

[Ronitsabhaya75]

@joyeecheung should i change the 5 seconds timeout to 1 second time out again?
the reason is all test are passing

[joyeecheung]

Did you mean that you want to just remove the flaky status in the PR? I don't think it's already proven that the flake is not flaky, so if you just remove it, it can fail the CI again. One passing CI does not mean that it would never reproduce again, that's the nature of flakes - it occasionally fail unrelated PRs but frequent enough to make the CI unusable because people keep seeing failures unrelated to their changes and have to run the CI many times to get a passing one.

[Ronitsabhaya75]

Did you mean that you want to just remove the flaky status in the PR? I don't think it's already proven that the flake is not flaky, so if you just remove it, it can fail the CI again. One passing CI does not mean that it would never reproduce again, that's the nature of flakes - it occasionally fail unrelated PRs but frequent enough to make the CI unusable because people keep seeing failures unrelated to their changes and have to run the CI many times to get a passing one.

I understood what you I'll remove that change and just keep the change of 1 second sleep to 5 second if it helps

[Ronitsabhaya75]

@joyeecheung i think this could fix the wasi flaky error i added the retry logic

[joyeecheung]

The changes in this file don't seem very relevant to me, ERR_WORKER_INIT_FAILED is emitted when a Node.js worker thread can't be initialized - mostly when the V8 heap cannot be initialized, but the flake happens when a native pthread can't be created, the test is structured in a way to load that WASM module that spawns the pthread and it's the module that's crashing, not the driver worker. Those are two different initializations and we are not seeing failures of worker thread initializations in the CI, only the pthread creation failures, so there's no need to change anything in how the driver worker is spawn.

[joyeecheung]

I don't think this is needed - again the failures don't seem related to the driver worker.

[joyeecheung]

Have you tried to reproduce locally to see exactly what error this is?

[Ronitsabhaya75]

@joyeecheung I was able regenerate the same error and was able to test it again and tried to fix it. I think you can review it now

[Ronitsabhaya75]

@joyeecheung can you please review this pr now pleasee

[joyeecheung]

Please refrain from continuous pinging. Looking into flakes is something that I only do at my spare time.

[Ronitsabhaya75]

I'm sorry I didn't know my bad🙏

[joyeecheung]

FWIW I don't think I've seen this in the CI (https://ci.nodejs.org/job/node-test-commit-arm-debug/ looks mostly green with only other failures every now and then) so that might've already been fixed by the split.

[Ronitsabhaya75]

gotcha I can close this PR and try to see if there is anything else I can work.

Thank you @joyeecheung for letting me know