test: fix http-client-timeout-option-listeners

[Trott]

Checklist

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

Affected core subsystem(s)

test http

Description of change

test-http-client-timeout-option-listeners is flaky due to depending on
completing operations before a 100ms socket timeout. The socket timeout
is an integral part of the test. Load on the machine can affect the
test, so move it to sequential.

[Trott]

Sample failure on CI:

https://ci.nodejs.org/job/node-test-commit-freebsd/5810/nodes=freebsd11-x64/console

not ok 465 parallel/test-http-client-timeout-option-listeners
  ---
  duration_ms: 0.551
  severity: fail
  stack: |-
    
    assert.js:85
      throw new assert.AssertionError({
      ^
    AssertionError: 0 === 1
        at common.mustCall (/usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/parallel/test-http-client-timeout-option-listeners.js:24:12)
        at /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd11-x64/test/common.js:416:15
        at _combinedTickCallback (internal/process/next_tick.js:71:11)
        at process._tickCallback (internal/process/next_tick.js:98:9)
  ...

[Trott]

On my machine, at least, this results in the test reliably failing, demonstrating that concurrency negatively impacts the test:

tools/test.py -j 32 test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js test/parallel/test-http-client-timeout-option-listeners.js

[Trott]

Error when failing with the above command is strikingly similar to the failure in CI, suggesting a similar cause:

assert.js:85
  throw new assert.AssertionError({
  ^
AssertionError: 0 === 1
    at common.mustCall (/Users/trott/io.js/test/parallel/test-http-client-timeout-option-listeners.js:26:14)
    at /Users/trott/io.js/test/common.js:416:15
    at _combinedTickCallback (internal/process/next_tick.js:71:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

[Trott]

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

[santigimeno]

The changes LGTM. As an alternative, what about setting a very large timeout? Do you think it makes sense?

diff --git a/test/parallel/test-http-client-timeout-option-listeners.js b/test/parallel/test-http-client-timeout-option-listeners.js
index 3ac6cd4..5e0f521 100644
--- a/test/parallel/test-http-client-timeout-option-listeners.js
+++ b/test/parallel/test-http-client-timeout-option-listeners.js
@@ -15,7 +15,7 @@ const options = {
   port: undefined,
   host: common.localhostIPv4,
   path: '/',
-  timeout: common.platformTimeout(100)
+  timeout: 2147483647
 };

[Trott]

The changes LGTM. As an alternative, what about setting a very large timeout? Do you think it makes sense?

Sure, we could use Number.MAX_SAFE_INTEGER or something like that for the timeout instead (or even in addition) if you (or anyone else) prefers. Either the move to sequential or the increase for the timeout should fix it. We could do one, the other, or both.

[santigimeno]

@Trott I thought about Number.MAX_SAFE_INTEGER but it seems its value (2^53 -1) is larger than the max timeout value: 2147483647

Either the move to sequential or the increase for the timeout should fix it. We could do one, the other, or both.

I agree. I prefer the latter as moving the test to sequential will lead to a minimal increase of the running time of the tests, but any of the proposed solutions are acceptable to me.

[Trott]

@santigimeno OK, I did it your way! PTAL!

[Trott]

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

[Trott]

Landed in 4a5c719.