test: investigate failing test-timers-unrefed-in-beforeexit

[jasnell]

parallel/test-timers-unrefed-in-beforeexit is suddenly failing in CI:
https://ci.nodejs.org/job/node-test-commit-linux/15434/nodes=alpine35-container-x64/console

not ok 1526 parallel/test-timers-unrefed-in-beforeexit
  ---
  duration_ms: 0.217
  severity: fail
  stack: |-
    assert.js:43
      throw new errors.AssertionError(obj);
      ^
    
    AssertionError [ERR_ASSERTION]: function should not have been called at /home/iojs/build/workspace/node-test-commit-linux/nodes/alpine35-container-x64/test/parallel/test-timers-unrefed-in-beforeexit.js:6
        at Timeout.mustNotCall [as _onTimeout] (/home/iojs/build/workspace/node-test-commit-linux/nodes/alpine35-container-x64/test/common/index.js:595:12)
        at ontimeout (timers.js:450:11)
        at Timer.unrefdHandle (timers.js:527:5)
  ...

@AndreasMadsen ... could this, by any chance, have anything to do with #18005?

[addaleax]

I think the test is flaky the way it is written anyway, 1ms might just be too short to make sure the event loop iteration is finished before the timer runs.

I guess increasing the timeout value to some much larger number should be okay, the test should still exit immediately.

[AndreasMadsen]

@jasnell I don't think so, #18005 should only change process.exit() and that isn't called anywhere here.

[jasnell]

Interesting... there's really nothing that I can see that would trigger this to be failing all of a sudden. I'm adding a commit in the PR where I'm seeing the failure that extends the timeout a bit. We'll see what happens :-)

[jasnell]

Ugh. Ok, setting the timeout up to 10 causes the test to fail with a different error ... specifically, beforeExit is called twice instead of just once. Hmm.

[Fishrock123]

Ugh. Ok, setting the timeout up to 10 causes the test to fail with a different error ... specifically, beforeExit is called twice instead of just once. Hmm.

Are you sure that this is what you did? It passes for me irrespective the duration.

The only way that could happen is if reuse() was broken, but I think there is more than one test which covers that?

[Fishrock123]

We should just be able to set it to require('internal/timers').TIMEOUT_MAX... I'll make a PR.

[apapirovski]

@Fishrock123 I don't think that's necessary. The failure has to do with the http2 binding.

[Fishrock123]

You mean the HTTP2 binding is keeping the loop alive? What's the parent issue for this?

[Fishrock123]

Parent issue: #18020

(Please look for other instances of the same test failure in the future! 😉)

[jasnell]

Will close this as it does appear to be an issue in the referenced PR... though certainly not an obvious one.

[apapirovski]

This is a legitimate bug although the test that it affects doesn't make the cause obvious (and http2 is a slight red herring). I've got a PR coming up.