Investigate flaky async-hooks.test-improper-unwind

Test

test/async-hooks/test-improper-unwind.js

Platform

AIX

Console output

---
duration_ms: 362.309
exitcode: 1
severity: fail
stack: |-
  node:assert:94
    throw new AssertionError(obj);
    ^

  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

  null !== 1

      at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/async-hooks/test-improper-unwind.js:59:12)
      at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/common/index.js:437:15)
      at ChildProcess.emit (node:events:507:28)
      at maybeClose (node:internal/child_process:1101:16)
      at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: null,
    expected: 1,
    operator: 'strictEqual'
  }

  Node.js v25.0.0-pre
...

Build links

Additional information

No response

cc @nodejs/async_hooks

This doesn't look like it is related to async hooks.
A child process is spawned but the close event of child process doesn't provide the exit code.
Could be also some issue in child process on aix or some temp resource limitation that child process couldn't be started. properly.

The child_process implementation in

node/lib/internal/child_process.js

Lines 262 to 275 in c969649

    
           this.signalCode = null; 
        
           this.exitCode = null; 
        
           this.killed = false; 
        
           this.spawnfile = null; 
        
           this._handle = new Process(); 
        
           this._handle[owner_symbol] = this; 
        
           this._handle.onexit = (exitCode, signalCode) => { 
        
             if (signalCode) { 
        
               this.signalCode = signalCode; 
        
             } else { 
        
               this.exitCode = exitCode; 
        
             }

shows that initially the signalCode and exitCode properties on the child process object are both set to null.

On exit:

if signalCode is truthy
- just the signalCode property is set with the new value
- and the exitCode property remains null
otherwise
- just the exitCode property is set with the new value
- and the signalCode property remains null

The child process is getting killed with a signal, that's why the 'close' callback is called with a null code and a truthy signal (we don't know what value this holds because it's not being logged). I think the test should log the signal and continue the assertions for now.