Repository navigation
Investigate flaky test-https-set-timeout-server on Raspberry Pi #14133
Description
Activity
- addedarmIssues and PRs related to the ARM architecture.Issues and PRs related to the ARM architecture.flaky-testIssues and PRs involving tests that fail intermittently in CI.Issues and PRs involving tests that fail intermittently in CI.httpsIssues and PRs related to the https subsystem.Issues and PRs related to the https subsystem.
on Jul 8, 2017 Problem might be solved by moving
cb()in all the test cases to inside a callback forserver.close()rather than invoking it immediately afterserver.close()is invoked. Same might have to happen in correspondinghttptest.(There could also be a case for moving each test into its own test file to rule out side effects.)
Moving the test to parallel and running it under load reproduces the issue.
$ tools/test.py -j92 --repeat 92 test/parallel/test-https-set-timeout-server.js === release test-https-set-timeout-server === Path: parallel/test-https-set-timeout-server Mismatched <anonymous> function calls. Expected exactly 1, actual 0. at Object.exports.mustCall (/Users/trott/io.js/test/common/index.js:484:10) at serverTimeout (/Users/trott/io.js/test/parallel/test-https-set-timeout-server.js:57:12) at /Users/trott/io.js/test/common/index.js:518:15 at run (/Users/trott/io.js/test/parallel/test-https-set-timeout-server.js:50:5) at _combinedTickCallback (internal/process/next_tick.js:131:7) at process._tickCallback (internal/process/next_tick.js:180:9) at Function.Module.runMain (module.js:607:11) at startup (bootstrap_node.js:158:16) at bootstrap_node.js:575:3 ...
If I comment out the first and last test case, the test becomes reliable.
@nodejs/http Is the following a bug or is it expected behavior?
Given this code:
const https = require('https'); const server = https.createServer( {key: keyfile, cert: certfile}, function connectionListener(req, res) { // just do nothing, we should get a timeout event. }); server.listen(() => { const s = server.setTimeout(50, (socket) => { socket.destroy(); server.close(); }); https.get({ port: server.address().port, rejectUnauthorized: false }).on('error', () => {}); });
...
connectionListener()may not run. Normally, it would. But it's not guaranteed as under load, the socket hangup/ECONNRESET may happen before the listener handler.Bug? Expected behavior? Incorrect observation on my part? Something else?
- added a commit that references this issue
on Jul 8, 2017 On the assumption that the behavior described in the above comment is Not A Bug, I've opened #14134.
- added 2 commits that reference this issue
on Jul 12, 2017 - added a commit that references this issue
on Jul 19, 2017 - added a commit that references this issue
on Sep 5, 2017 - added a commit that references this issue
on Jul 27, 2026
https://ci.nodejs.org/job/node-test-binary-arm/9111/RUN_SUBSET=0,label=pi1-raspbian-wheezy/console
@nodejs/testing @nodejs/http