| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
I think we've been removing these kinds of checks to avoid timeout-related flakiness in tests -- the test runner enforces its own timeout anyway. (/cc @Trott)
If you want to have actual timing guarantees, you can try to remove the dependency on networking and use something like test/parallel/test-http2-generic-streams.js does.
Sorry, something went wrong.
There was a problem hiding this comment.
Other things to be aware of, just sorta FYI, you don't need to do anything with these at this time unless you think you should:
Tests with timers like this can become unreliable if the test is competing with other tests for resources. This unreliability is introduced surprisingly often on a few platforms in CI (particularly FreeBSD, I think because test.py decides it has 48 processors or something but they're not "real" processors--never really dug into it TBH, but you get the idea). To avoid the problem, the test can be put in sequential rather than parallel.
If you think 10 seconds is plenty for most things, but that maybe a Raspberry Pi could use a little more time than that, use common.platformTimeout().
Sorry, something went wrong.
There was a problem hiding this comment.
👍
Sorry, something went wrong.
There was a problem hiding this comment.
I think this could be common.mustCallAtLeast()'ed, to make sure it's run?
Sorry, something went wrong.
There was a problem hiding this comment.
Since it's a once handler, it could be common.mustCall().
If the test will fail without the handler running, then I'm OK omitting common.mustCall(). And I'm OK including it. Either way...
Sorry, something went wrong.
There was a problem hiding this comment.
fixed. added a mustCall, since it's a once.
Sorry, something went wrong.
I did the rebase, so no need to worry about that anymore. |
Sorry, something went wrong.
|
@nodejs/http2 @nodejs/testing |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
|
This test is failing and it is showing a bug :/. I've run why-is-node-running with it, and we just have: There are 7 handle(s) keeping the process running
# Timeout
/Users/matteo/Repositories/node/test/parallel/test-http2-many-writes-and-destroy.js:35 - setTimeout(function () {
# TCPWRAP
/Users/matteo/Repositories/node/test/parallel/test-http2-many-writes-and-destroy.js:17 - const client = http2.connect(url);
# HTTP2SESSION
(unknown stack trace)
# HTTP2SETTINGS
(unknown stack trace)
# Timeout
(unknown stack trace)
# HTTP2SESSION
(unknown stack trace)
# HTTP2STREAM
(unknown stack trace)
I have a possible fix coming, pushing directly to this PR. |
Sorry, something went wrong.
Sorry, something went wrong.
|
🎉 @mcollina added a fix for my failing test case \o/ |
Sorry, something went wrong.
| if (!socket.destroyed) { | ||
| if (!error) { | ||
| setImmediate(socket.end.bind(socket)); | ||
| setImmediate(socket.destroy.bind(socket)); |
There was a problem hiding this comment.
oy! obvious and simple in hindsight.
Sorry, something went wrong.
There was a problem hiding this comment.
a classic @mcollina fix :)
Sorry, something went wrong.
|
LGTM, especially with the fix :-) |
Sorry, something went wrong.
|
Rerunning the CI because there were a couple of failures https://ci.nodejs.org/job/node-test-pull-request/14265/ |
Sorry, something went wrong.
|
@mafintosh Can you make sure that the CI failures are unrelated? In particular, at a quick glance https://ci.nodejs.org/job/node-test-commit-osx/17798/nodes=osx1010/console might not be… |
Sorry, something went wrong.
Sorry, something went wrong.
|
@apapirovski I've added your commit on top. |
Sorry, something went wrong.
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-pull-request/14792/ I added some other fixes for the new changes. I also removed the changes to the http2 pipe test because if that one's getting an ECONNRESET then we shouldn't swallow it. That would indicate the fix here isn't fully correct (e.g. it's possible for us to be still writing meaningful data when the socket is destroyed). |
Sorry, something went wrong.
|
Ok, the CI is green FWIW. If someone wants to give this a few more looks then we could go ahead and finally land this. (Another CI just to be safe: https://ci.nodejs.org/job/node-test-pull-request/14805/) |
Sorry, something went wrong.
Sorry, something went wrong.
|
Still LGTM |
Sorry, something went wrong.
Fix a bug where the socket wasn't being correctly destroyed and adjust existing tests, as well as add additional tests. PR-URL: #19852 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Co-authored-by: Matteo Collina <matteo.collina@gmail.com>
Fix a bug where the socket wasn't being correctly destroyed and adjust existing tests, as well as add additional tests. PR-URL: #19852 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Co-authored-by: Matteo Collina <matteo.collina@gmail.com>
Fix a bug where the socket wasn't being correctly destroyed and adjust existing tests, as well as add additional tests. PR-URL: #19852 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Co-authored-by: Matteo Collina <matteo.collina@gmail.com>
Fix a bug where the socket wasn't being correctly destroyed and adjust existing tests, as well as add additional tests. PR-URL: #19852 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com> Co-authored-by: Matteo Collina <matteo.collina@gmail.com>
| Back | FazBrowse Home | New Git URL |
Checklist
Simplified the failing http2 test from #19828 into this test case. Basically when doing lots of writes and then destroying the request, the process will hang instead of exiting normally.
Fixes #20630