test: http2 client operations after destroy

[trivikr]

This code change tests client operations after calling client.destroy()

Refs: #14985

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

test, http2

[watilde]

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

[apapirovski]

Looks like this failed on ubuntu1604-arm64, see https://ci.nodejs.org/job/node-test-commit-arm/nodes=ubuntu1604-arm64/12673/tapResults/

[apapirovski]

This should be common.platformTimeout(10) — I would also strongly recommend trying to find a way to avoid the timeout. In general we try to avoid using timeout unless it's part of what's being tested.

(I haven't looked at the code so I don't know if it's possible. Perhaps there's an event emitted later on that can be piggy backed on? Or would setImmediate work here, since the other setImmediate is probably enqueued first?)

[trivikr]

The destroy method calls finishSessionDestroy in a setImmediate at

node/lib/internal/http2/core.js

Line 974 in e399abd

setImmediate(finishSessionDestroy, this, socket);

While writing tests, I've to wait for finishSessionDestroy to complete and setTimeout is called after setImmediate (stackoverflow discussion)

I replaced setTimeout with setImmediate and the test was successful. I'l updated the commit.

[joyeecheung]

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

[trivikr]

CI build is successful, this change should be good to merge.

[Trott]

CI build is successful, this change should be good to merge.

I'm afraid that's incorrect. There's something wrong with CI and no tests were actually run. It will need to be re-run.

[joyeecheung]

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

[trivikr]

The CI is failing on slower platforms https://ci.nodejs.org/job/node-test-commit/13123//console
I've updated commit using setTimeout with common.platformTimeout() instead of setImmediate, as recommended in the documentation

[apapirovski]

While node-test-commit-arm-fanned did fail, I don't see any failures that are caused by this PR. Could someone else double-check please?

[Trott]

Arbitrary timeouts like this are a sign of an unreliable test more often than not. Can we find another way to solve whatever problem it is supposed to solve? Listening for events or even an unfortunate setInterval() for polling would be preferable IMO. If the test absolutely must use common.platformTimeout(), chances are that it should be moved to sequential.

[Trott]

Here's this chunk of code rewritten with a polling setInterval():

      const interval = setInterval(() => {
        if (client.destroyed) {
          clearInterval(interval);
          common.expectsError(() => client.request(), sessionError);
          common.expectsError(() => client.settings({}), sessionError);
          common.expectsError(() => client.priority(req, {}), sessionError);
          common.expectsError(() => client.shutdown(), sessionError);
          common.expectsError(() => client.rstStream(req), sessionError);          
        }
      }, 1);

Using that instead makes it reliable under load:

$ tools/test.py -j 96 --repeat 192 test/parallel/test-http2-client-destroy.js 
[00:12|% 100|+ 192|-   0]: Done                              
$

For comparison, here's what happens with the current version of this PR (using setTimeout() and common.platformTimeout():

$ tools/test.py -j 96 --repeat 192 test/parallel/test-http2-client-destroy.js 
=== release test-http2-client-destroy ===                    
Path: parallel/test-http2-client-destroy
(node:22883) ExperimentalWarning: The http2 module is an experimental API.
assert.js:42
  throw new errors.AssertionError({
  ^

AssertionError [ERR_ASSERTION]: Missing expected exception.
    at innerThrows (assert.js:186:7)
    at Function.throws (assert.js:205:3)
    at Object.expectsError (/Users/trott/io.js/test/common/index.js:746:12)
    at Timeout.setTimeout [as _onTimeout] (/Users/trott/io.js/test/parallel/test-http2-client-destroy.js:105:16)
    at ontimeout (timers.js:474:11)
    at tryOnTimeout (timers.js:298:5)
    at Timer.listOnTimeout (timers.js:258:5)
Command: out/Release/node /Users/trott/io.js/test/parallel/test-http2-client-destroy.js
=== release test-http2-client-destroy ===                   
Path: parallel/test-http2-client-destroy
(node:22846) ExperimentalWarning: The http2 module is an experimental API.
assert.js:42
  throw new errors.AssertionError({
  ^

AssertionError [ERR_ASSERTION]: Missing expected exception.
    at innerThrows (assert.js:186:7)
    at Function.throws (assert.js:205:3)
    at Object.expectsError (/Users/trott/io.js/test/common/index.js:746:12)
    at Timeout.setTimeout [as _onTimeout] (/Users/trott/io.js/test/parallel/test-http2-client-destroy.js:105:16)
    at ontimeout (timers.js:474:11)
    at tryOnTimeout (timers.js:298:5)
    at Timer.listOnTimeout (timers.js:258:5)
Command: out/Release/node /Users/trott/io.js/test/parallel/test-http2-client-destroy.js
[00:11|% 100|+ 190|-   2]: Done                             
$

[apapirovski]

As far as I can tell, this never fails with setImmediate. (If setImmediate fails then there's a bug in http2 so it's strictly the correct choice here.)

Machine:nodejs apapirovski$ tools/test.py -j 96 --repeat 960 test/parallel/test-http2-client-destroy.js
[00:30|% 100|+ 960|-   0]: Done                              

I don't really understand why it was changed from that to setTimeout when the previous CI ran successfully.

[Trott]

I too am also seeing 100% success with setImmediate(). Putting it back to that is probably the most elegant solution. CI failures seem unrelated to this PR.

(Speaking of Ci challenges: Anybody good with Jenkins and/or ansible and/or systems administration would probably make a great addition to the Build WG. If that sounds like you and you are a known quantity around these parts, maybe nominate yourself with an issue in https://github.com/nodejs/build? There are some talented folks on that team, but we probably could use many more active members.)

[trivikr]

Switched to setImmediate() in the new commit
@Trott Can you create a new issue for CI challenges and reference this PR?

setImmediate() has been restored, thanks

[Trott]

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

[jasnell]

Landed in 68df587