-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Add test for HTTP client "aborted" event #7376
Conversation
'use strict'; | ||
require('../common'); | ||
var http = require('http'); | ||
var assert = require('assert'); |
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.
We usually use const
instead of var
wherever it makes sense.
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.
Update the other tests, as well?
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.
It should be perfectly fine to change these just here – formatting changes tend to mess up the history/git blame
, so it’s always easier to do them in new code/code that’s being touched anyway.
Thanks, this is generally looking good… I know the other tests don’t always hold up to what is usually expected from new ones. :) again, /cc @nodejs/http |
If the fixes are obvious, please feel free to hack up what I've tried to do. I'm by no means territorial about it... |
@kemitchell That’s completely up to you, if you prefer, I guess I could PR against your branch (definitely later, though). There’s also resources like https://github.com/nodejs/node/blob/master/doc/guides/writing_tests.md#test-structure if you’re interested. (And, sorry if I’m misunderstanding you language-barrier-wise…?) |
Hey, @kemitchell! Thanks for putting this together. There are a number of conventions in tests and elsewhere in the code that aren't checked by the linter unfortunately. This is because (for example) converting all those Anyway, since you're so close on this one, I went ahead and put together what I think is what the various nits above are after. Feel free to cut-and-paste and commit to your branch, or otherwise use in whatever way you find useful. Use it as a starting point, or just look at it and ask questions if stuff doesn't make sense, or ignore me completely. Whatever works for you. 'use strict';
const common = require('../common');
const http = require('http');
const server = http.Server(function(req, res) {
console.log('Server accepted request.');
res.write('Part of my res.');
res.destroy();
});
const requiredCallback = common.mustCall(function() {
console.log('Response aborted.');
});
server.listen(0, function() {
http.get({
port: this.address().port,
headers: { connection: 'keep-alive' }
}, function(res) {
server.close();
console.log('Got res: ' + res.statusCode);
res.on('aborted', requiredCallback);
});
}); |
2682eef
to
44534dd
Compare
44534dd
to
ae27d11
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request/3098/ (@kemitchell You're not giving yourself enough credit.) |
const http = require('http'); | ||
|
||
const server = http.Server(function(req, res) { | ||
console.log('Server accepted request.'); |
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.
Are the console.log
outputs necessary?
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.
It should not be, even further it may break the TAP.
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've got no problem at all with seeing the console.log()
calls removed. But I'm curious about the TAP comment. I'm pretty sure test.py
or whatever captures the test's stdout and stderr and does not interleave it with TAP output. Is there a subtlety I'm missing where a console.log()
can cause problems with TAP in that case? Many (perhaps even most) of our tests do console.log()
and/or console.error()
. So if this is A Thing, I'd definitely like to know more. (/cc @nodejs/testing)
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.
Oh, wait, we definitely directly output TAP sometimes from JS (e.g., when a test is skipped), so yeah, I guess it is A Thing...
LGTM with a nit |
console.log('Response aborted.'); | ||
}); | ||
|
||
server.listen(0, function() { |
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.
Any reason not to use common.PORT
here?
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.
common.PORT
has the downside of making subsequent tests fail with EADDRINUSE
if one test does not clean up after itself (due to failure, programming error, some kind of OS flakiness, or whatever). There was a bit of an effort for a while to stamp it out except in the few places that absolutely need it. I think @mscdex was at the center of that, but I may be mis-remembering.
Anyway, in general, I prefer to see server.listen(0, ...)
over server.listen(common.PORT, ...)
if at all possible.
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.
LGTM with two nits. |
ae27d11
to
cd2b014
Compare
|
@indutny I removed the |
@kemitchell The other nit involved suggesting |
Yeah, I don't feel strongly about it. LGTM |
New CI following updates: https://ci.nodejs.org/job/node-test-pull-request/3112/ |
@jasnell: Sorry. Did I break it? |
Nope! It does look like we have a couple of infrastructure hiccups tho. Going to run it again. |
@kemitchell ... actually, looks like we have a couple of linting issues:
|
cd2b014
to
09fcb10
Compare
@jasnell: Last force-push hopefully fixed lint issues. |
headers: { connection: 'keep-alive' } | ||
}, function(res) { | ||
server.close(); | ||
res.on('aborted', common.mustCall(function() { return; })); |
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.
Nit: can you get rid of the return
statement? It is not really useful.
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.
Amended.
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.
More callbacks could be wrapped with common.mustCall
but if the response
event is not emitted on the http.ClientRequest
the test would fail anyway for timeout.
LGTM
09fcb10
to
ae28dcf
Compare
res.destroy(); | ||
}); | ||
|
||
server.listen(0, function() { |
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.
Please add a common.mustCall()
here.
http.get({ | ||
port: this.address().port, | ||
headers: { connection: 'keep-alive' } | ||
}, function(res) { |
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.
And a common.mustCall()
here.
headers: { connection: 'keep-alive' } | ||
}, function(res) { | ||
server.close(); | ||
res.on('aborted', common.mustCall(function() { })); |
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.
No need for the space inside the empty curly braces.
With @cjihrig's nits addressed, yes. |
c133999
to
83c7a88
Compare
ae28dcf
to
142e3c4
Compare
I have amended to add There are a few more places where the same space could go:
I hope these changes do it. Unfortunately, I haven't time or bandwidth to follow this PR any further. If it needs additional love, please feel free to amend as y'all see fit, either on merge or on my branch, as "edits from maintainers". Sincerest thanks to all for time and attention on this and so much else that makes Node work. Thanks especially to @Trott. IIRC, this code is mostly his at this point ;-) |
I'll land this tomorrow if there are no objections. |
One last CI run: https://ci.nodejs.org/job/node-test-pull-request/4759/ |
PR-URL: nodejs#7376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Landed in 6d6f9e5. |
Thanks to all! |
PR-URL: #7376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: #7376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: #7376 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Fedor Indutny <fedor@indutny.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Checklist
make -j4 test
(UNIX) orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
None. A test for current
http
.Description of change
Following on from #7270 to add a test for
aborted
events onhttp.IncomingMessage
emitters fromhttp.request
. New test was derived from old test/parallel/test-http-abort-client.js.cc @addaleax