Skip to content

investigate flaky test-child-process-exec-abortcontroller-promisified on Windows CI #37568

Description

@Trott

Surprised there isn't already an issue for this one. It's been happening a lot lately. I think it is only on the 32-bit Windows in CI.

Here's an example:

  • Test: test-child-process-exec-abortcontroller-promisified
  • Platform: Win2012r2 VS 2013 x64 (test-rackspace-win2012r2_vs2013-x64-1)
  • Console Output:
00:29:58 not ok 72 parallel/test-child-process-exec-abortcontroller-promisified
00:29:58   ---
00:29:58   duration_ms: 0.174
00:29:58   severity: fail
00:29:58   exitcode: 1
00:29:58   stack: |-
00:29:58     node:internal/process/promises:245
00:29:58               triggerUncaughtException(err, true /* fromPromise */);
00:29:58               ^
00:29:58     
00:29:58     [AssertionError [ERR_ASSERTION]: post aborted sync signal failed] {
00:29:58       generatedMessage: false,
00:29:58       code: 'ERR_ASSERTION',
00:29:58       actual: Error: Command failed: TIMEOUT 120
00:29:58       ERROR: Input redirection is not supported, exiting the process immediately.
00:29:58     
00:29:58       
00:29:58           at ChildProcess.exithandler (node:child_process:326:12)
00:29:58           at ChildProcess.emit (node:events:378:20)
00:29:58           at maybeClose (node:internal/child_process:1067:16)
00:29:58           at Socket.<anonymous> (node:internal/child_process:453:11)
00:29:58           at Socket.emit (node:events:378:20)
00:29:58           at Pipe.<anonymous> (node:net:671:12) {
00:29:58         killed: false,
00:29:58         code: 1,
00:29:58         signal: null,
00:29:58         cmd: 'TIMEOUT 120',
00:29:58         stdout: '',
00:29:58         stderr: 'ERROR: Input redirection is not supported, exiting the process immediately.\r\n'
00:29:58       },
00:29:58       expected: /AbortError/,
00:29:58       operator: 'rejects'
00:29:58     }
00:29:58   ...

Activity

  1. Trott commented on Mar 2, 2021

    @Trott
    MemberAuthor

    This seems likely to have been introduced by #37325. @Linkgoron @benjamingr

  2. Trott commented on Mar 2, 2021

    @Trott
    MemberAuthor

    @nodejs/testing @nodejs/platform-windows @nodejs/child_process

  3. added
    child_processIssues and PRs related to the child_process subsystem.
    flaky-testIssues and PRs involving tests that fail intermittently in CI.
    windowsIssues and PRs related to the Windows platform.
    on Mar 2, 2021
  4. Linkgoron commented on Mar 2, 2021

    @Linkgoron
    Contributor

    Yes, this is obviously my added test. Looks an issue with background timeout:
    https://www.ibm.com/support/pages/timeout-command-run-batch-job-exits-immediately-and-returns-error-input-redirection-not-supported-exiting-process-immediately

    I'd be happy to replace the timeout command with anything long-running. The test needs something long-running enough to give the node process time to kill it. The above suggests using ping -n 10 127.0.0.1 >NUL (for a 10 second pause). Another option on Windows would be executing a node process with the "never-ending" js fixture. Originally, that was how I wanted to write the test but it doesn't work on Linux (as killing the cp that's created with exec on linux doesn't kill the underlying Node process because of the shell, but on windows it works as expected).

    Have you seen any issues with the sleep command, which is what I used on Linux?

  5. aduh95 commented on Mar 2, 2021

    @aduh95
    Contributor

    Could we use node -e 'setTimeout(()=>{}, 9999)'? It should be cross platform work on Windows.

  6. Trott commented on Mar 2, 2021

    @Trott
    MemberAuthor

    Could we use node -e 'setTimeout(()=>{}, 9999)'? It should be cross plateform.

    Or even node -e 'setInterval(()=>{}, 9999)'? (The overall test timeout is handled by tools/test.py so we can rely on that for platform-specific timeouts automatically.)

  7. Linkgoron commented on Mar 2, 2021

    @Linkgoron
    Contributor

    Could we use node -e 'setTimeout(()=>{}, 9999)'? It should be cross plateform.

    Yes, but it needs something with a low enough timeout, so that it would die close enough to the end of the test but also high enough so that it would 100% get killed by the node process (test) before the timeout is up. The issue is that at the end of the tests, the tests use ps awwx to check if there's a node process that's still running.

    @Trott setInterval didn't work for me, that was my original solution - before relying on TIMEOUT/sleep. see #37518

  8. Linkgoron commented on Mar 2, 2021

    @Linkgoron
    Contributor

    Could we use node -e 'setTimeout(()=>{}, 9999)'? It should be cross platform work on Windows.

    On Windows, even setInterval would work

  9. aduh95 commented on Mar 2, 2021

    @aduh95
    Contributor

    A potential fix would be to keep using sleep on linux, and use setInterval everywhere else, right?

  10. Linkgoron commented on Mar 2, 2021

    @Linkgoron
    Contributor

    I'm not sure why we would change everything if the issue is only on windows, but your fix should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    child_processIssues and PRs related to the child_process subsystem.flaky-testIssues and PRs involving tests that fail intermittently in CI.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions