-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: fix flaky test-http-set-timeout-server #11790
test: fix flaky test-http-set-timeout-server #11790
Conversation
@@ -117,20 +117,25 @@ test(function serverRequestNotTimeoutAfterEnd(cb) { | |||
|
|||
test(function serverResponseTimeoutWithPipeline(cb) { | |||
let caughtTimeout = ''; | |||
let secReceived = false; | |||
process.on('exit', function() { | |||
assert.strictEqual(caughtTimeout, '/2'); | |||
}); | |||
const server = http.createServer(function(req, 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.
may be worthwhile adding in common.mustCall()
for the various callbacks in this test.
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 thought of that but it's tricky because the number of times the callbacks are run depends on when the timer fires. I can wrap the http.createServer()
callback though
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 don't know if I can wrap the http.createServer()
callback either as I'm not sure it's going to be called always 3 times.
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.
hmm.. ok.
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.
Nice! LGTM if CI is ✅
CI: https://ci.nodejs.org/job/node-test-commit/8407/
Any other platforms that we should stress test? EDIT: It seems like the test is failing on the PR branch at a similar frequency to master when run in parallel. |
@gibfahn the first stress test does not seem to use the code in this PR. I've started a new one: https://ci.nodejs.org/job/node-stress-single-test/1132/ |
@santigimeno sorry about that, had to rerun several times, must have got the PR number confused at some point. |
Stress test on master failed while stress test with this PR passed. |
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: nodejs#11790 Fixes: nodejs#11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
8d0434f
to
3be1db8
Compare
Landed in 3be1db8. Thanks. |
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: nodejs#11790 Fixes: nodejs#11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: nodejs#11790 Fixes: nodejs#11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: #11790 Fixes: #11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: #11790 Fixes: #11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
This might still be flaky, I currently don't have time to investigate (node-test-binary-arm#8941):
|
It can happen that the connection and server is closed before the second reponse has been processed by server. In this case, the `res.setTimeout()` callback will never be called causing the test to fail. Fix this by only closing the connection and server when the 2nd has been received. PR-URL: nodejs/node#11790 Fixes: nodejs/node#11768 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
It can happen that the connection and server is closed before the second
reponse has been processed by server. In this case, the
res.setTimeout()
callback will never be called causing the test tofail. Fix this by only closing the connection and server when the 2nd
has been received.
Fixes: #11768
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test