-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: http2 client operations after destroy #16094
Conversation
Looks like this failed on |
common.expectsError(() => client.priority(req, {}), sessionError); | ||
common.expectsError(() => client.shutdown(), sessionError); | ||
common.expectsError(() => client.rstStream(req), sessionError); | ||
}, 10); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
5149496
to
25b5f86
Compare
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. |
25b5f86
to
3fd6b13
Compare
The CI is failing on slower platforms https://ci.nodejs.org/job/node-test-commit/13123//console |
While |
common.expectsError(() => client.priority(req, {}), sessionError); | ||
common.expectsError(() => client.shutdown(), sessionError); | ||
common.expectsError(() => client.rstStream(req), sessionError); | ||
}, common.platformTimeout(100)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
$
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to setImmediate()
in the new commit
@Trott Can you create a new issue for CI challenges and reference this PR?
3fd6b13
to
d7e0ae4
Compare
PR-URL: #16094 Ref: #14985 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
Landed in 68df587 |
PR-URL: #16094 Ref: #14985 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
PR-URL: nodejs/node#16094 Ref: nodejs/node#14985 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Daijiro Wachi <[email protected]>
This code change tests client operations after calling
client.destroy()
Refs: #14985
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, http2