test: fix flaky test-process-fatal-execption-tick.js

[Trott]

test-process-fatal-execption-tick.js is sensitive to load. On a loaded
machine, it will fail. Move it to sequential so that it does not compete
for resources.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

test

[Trott]

Sample CI failure:

https://ci.nodejs.org/job/node-test-commit-linux/15941/nodes=fedora24/console

not ok 1242 parallel/test-process-fatal-exception-tick
  ---
  duration_ms: 0.294
  severity: fail
  stack: |-
    assert.js:72
      throw new AssertionError(obj);
      ^
    
    AssertionError [ERR_ASSERTION]: 1 strictEqual 2
        at process.nextTick (/home/iojs/build/workspace/node-test-commit-linux/nodes/fedora24/test/parallel/test-process-fatal-exception-tick.js:19:33)
        at process._tickCallback (internal/process/next_tick.js:89:11)
  ...

[Trott]

How to replicate locally:

$ tools/test.py -j 96 --repeat 192 test/parallel/test-process-fatal-exception-tick.js 
=== release test-process-fatal-exception-tick ===                    
Path: parallel/test-process-fatal-exception-tick
assert.js:72
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: 1 strictEqual 2
    at process.nextTick (/Users/trott/io.js/test/parallel/test-process-fatal-exception-tick.js:19:33)
    at process._tickCallback (internal/process/next_tick.js:89:11)
Command: out/Release/node /Users/trott/io.js/test/parallel/test-process-fatal-exception-tick.js
[00:07|% 100|+ 191|-   1]: Done    
$ 

[Trott]

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

[apapirovski]

@Trott could you instead remove line 21 and replace line 23 with common.busyLoop(50);? I tested it locally and that didn't fail a single time in 960 tries.

(Would prefer as few sequential tests as possible.)

[Trott]

@Trott could you instead remove line 21 and replace line 23 with common.busyLoop(50);? I tested it locally and that didn't fail a single time in 960 tries.

I can't make it fail even with common.busyLoop(1). Can you? There's something else going on there. (Maybe function-calling overhead?)

I'm fine with using common.busyLoop() (although I'd want to know why it doesn't fail with even a value of 1 first), but I'd still recommend keeping it in sequential because (IMO) anything with an arbitrary duration should be there and not in parallel.

[apapirovski]

I can't make it fail even with common.busyLoop(1). Can you? There's something else going on there. (Maybe function-calling overhead?)

It calls into C++ and libuv so it's definitely different semantics from using Date.now(). I would still prefer to keep it in parallel because any extra tests in sequential extend the overall running time of tests but I'm fine with moving it if you prefer.

[Trott]

OK, we'll try it that way. Used common.busyLoop(10) and put it back in parallel.

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

[Trott]

OMG! First yellow CI in dozens of runs! Let's land this thing! :-D

@nodejs/testing

[Trott]

Landed in a025723

[MylesBorins]

Test doesn't exist on v9.x, setting as don't land