You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
not ok 399 sequential/test-http-server-consumed-timeout --- duration_ms: 1.41 severity: fail stack: |- assert.js:48 throw new errors.AssertionError({ ^ AssertionError [ERR_ASSERTION]: Request timeout should not fire at IncomingMessage.mustNotCall (c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vs2017\label\win2016\test\common\index.js:563:12) at emitOne (events.js:115:13) at IncomingMessage.emit (events.js:210:7) at Socket.socketOnTimeout (_http_server.js:389:48) at emitNone (events.js:105:13) at Socket.emit (events.js:207:7) at Socket._onTimeout (net.js:402:8) at ontimeout (timers.js:469:11) at tryOnTimeout (timers.js:304:5) at Timer.listOnTimeout (timers.js:264:5)
not ok 1661 sequential/test-http-server-consumed-timeout
---
duration_ms: 0.559
severity: fail
stack: |-
assert.js:42
throw new errors.AssertionError({
^
AssertionError [ERR_ASSERTION]: Request timeout should not fire
at IncomingMessage.mustNotCall (/data/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel72-s390x/test/common/index.js:560:12)
at emitOne (events.js:115:13)
at IncomingMessage.emit (events.js:210:7)
at Socket.socketOnTimeout (_http_server.js:389:48)
at emitNone (events.js:105:13)
at Socket.emit (events.js:207:7)
at Socket._onTimeout (net.js:400:8)
at ontimeout (timers.js:469:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:264:5)
...
changed the title [-]investigate flaky sequential/test-http-server-consumed-timeout on Windows[/-][+]investigate flaky "sequential/test-http-server-consumed-timeout"[/+]on Aug 13, 2017
Because there's always a chance that a 25ms timeout will take longer than 200ms to actually be invoked, there's always going to be a chance that this test (as written) will fail spuriously. However, I think I see a way to reduce the frequency by an order of magnitude or two...
Activity
refack commentedon Aug 13, 2017
Showed up on linuxONE
https://ci.nodejs.org/job/node-test-commit-linuxone/7940/nodes=rhel72-s390x/console
Stress test indicate 0.1% failures - https://ci.nodejs.org/job/node-stress-single-test/1373/nodes=rhel72-s390x/
[-]investigate flaky sequential/test-http-server-consumed-timeout on Windows[/-][+]investigate flaky "sequential/test-http-server-consumed-timeout"[/+]BridgeAR commentedon Sep 28, 2017
@nodejs/testing are we just going to live with the test being flaky at times?
Trott commentedon Sep 29, 2017
Because there's always a chance that a 25ms timeout will take longer than 200ms to actually be invoked, there's always going to be a chance that this test (as written) will fail spuriously. However, I think I see a way to reduce the frequency by an order of magnitude or two...
First, though, CI stress on current master to confirm we still have a measurable problem: https://ci.nodejs.org/job/node-stress-single-test/1427/nodes=rhel72-s390x/console
test: skip test if host is too slow
Trott commentedon Sep 29, 2017
OK, I'm able to get it to 100% reliability as long as we're OK with skipping the test in unfavorable conditions. See #15688
test: skip test if host is too slow
test: skip test if host is too slow
test: skip test if host is too slow
test: skip test if host is too slow
test: skip test if host is too slow
test: skip test if host is too slow