test: add mustCall() to test-inspector-contexts #30649

Trott · 2019-11-26T06:15:57Z

In test-inspector-contexts, if mainContextPromise is modified such that
the method argument is changed to something invalid, the test still
passes and the second part of the test never runs. Use
common.mustCall() to cause the test to fail if the second part of the
test does not run.

Refs: #30519 (comment)

Checklist

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

Trott · 2019-11-26T06:25:00Z

Added a second commit to check for errors in session.post() by adding a callback.

Trott · 2019-11-26T07:04:55Z

Added a third commit to remove destructuring that was making the test harder to read/understand, at least for me.

Added a fourth commit to add logging for a possible/probable infinite loop (or infinite-ish loop) that may be why the test times out sometimes on CI.

Trott · 2019-11-26T18:21:13Z

@nodejs/testing @nodejs/inspector

Trott · 2019-11-27T05:49:18Z

@nodejs/collaborators

test/sequential/test-inspector-contexts.js

nodejs-github-bot · 2019-11-27T21:11:31Z

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

Trott · 2019-11-27T21:31:32Z

Welp, this at least has the desired effect of supplying more information about why test-inspector-contexts sometimes hangs in CI.

13:29:09 not ok 1312 sequential/test-inspector-contexts
13:29:09   ---
13:29:09   duration_ms: 149.140
13:29:09   severity: fail
13:29:09   exitcode: 1
13:29:09   stack: |-
13:29:09     timeout
13:29:09     Testing context created/destroyed notifications
13:29:09     Checking/waiting for GC.
13:29:09   ...

So it looks like it just runs the first global.gc() over and over and the context is never garbage collected/destroyed?

Trott · 2019-11-28T06:40:29Z

Landed in ea7a6f9...15146e6

In test-inspector-contexts, if mainContextPromise is modified such that the `method` argument is changed to something invalid, the test still passes and the second part of the test never runs. Use `common.mustCall()` to cause the test to fail if the second part of the test does not run. Refs: #30519 (comment) PR-URL: #30649 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

If session.post() generates an error, it is currently ignored. Add check for error by adding a callback to session.post() invocation. PR-URL: #30649 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

As I'm working with this test, I'm finding the destructuring of assert and vm to make this test harder to read/understand. So I'm taking the liberty of removing them. PR-URL: #30649 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

test-inspector-contexts may be entering an infinite loop (or very long-running loop) in CI, resulting in flakiness. Or maybe not. Add logging to find out. PR-URL: #30649 Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Denys Otrishko <shishugi@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>