Repository navigation
test: investigate flakiness of parallel/test-async-wrap-getasyncid #13020
Description
- Version:
master - Platform: Windows
smartos15-64++ - Subsystem: test,async-hooks
file:
https://github.com/nodejs/node/blob/master/test/parallel/test-async-wrap-getasyncid.js
falakings
- https://ci.nodejs.org/job/node-test-binary-windows/8471/
- https://ci.nodejs.org/job/node-test-binary-windows/8362/
- https://ci.nodejs.org/job/node-test-binary-windows/8402/
TAP output
2 parallel/test-async-wrap-getasyncid
duration_ms 0.232
severity fail
stack
Mismatched <anonymous> function calls. Expected 1, actual 0.
at Object.<anonymous> (c:\workspace\node-test-binary-windows\RUN_SUBSET\3\VS_VERSION\vs2015\label\win2008r2\test\parallel\test-async-wrap-getasyncid.js:155:42)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Function.Module.runMain (module.js:605:10)
at startup (bootstrap_node.js:144:16)
at bootstrap_node.js:561:3
(node:5848) [DEP0064] DeprecationWarning: tls.createSecurePair() is deprecated. Please use tls.Socket instead.
Hypothesis
Seems like a net.server sometimes doesn't complete it's creation before the test exits...
const server = net.createServer(common.mustCall((socket) => {
Activity
[-]test: investigate flakiness of test-async-wrap-getasyncid (on windows[/-][+]test: investigate flakiness of `parallal/test-async-wrap-getasyncid` (on windows)[/+]refack commentedon May 14, 2017
Stress CI: https://ci.nodejs.org/job/node-stress-single-test/1219/nodes=win10/
refack commentedon May 14, 2017
@addaleax @AndreasMadsen is it possible that the anonymous scope + eager
gccalls, cleans up the server before it has a chance to(h)->flags = UV__HANDLE_REF?addaleax commentedon May 14, 2017
As far as I understand
common.mustCall(), all missed functions are listed on exit. If you were right, that would mean that the.listen()handler wouldn’t get called, but it’s not listed so it seems safe to assume it does get called?AndreasMadsen commentedon May 14, 2017
The only explanation that makes sense to me, is that the client connects, sends data, and shutdown itself before the actual server received any connection. Thus the libuv loop doesn't know that there a connection incoming and will just exit the process.
We could wait until the server received its connection before running
handle.shutdown()or alternatively simply remove thecommon.mustCallfromnet.createServer().In any case, the
net.createServer()should actually not callsocket.end();orsocket.destroy();since that creates a race conditon betweensocket.destroy();andhandle.shutdown().refack commentedon May 14, 2017
Yep...
👍
handle.shutdown()only inreq.on('end')I'm on it.
AndreasMadsen commentedon May 14, 2017
We need to wait for both
server.on('connection')andwreq.oncomplete. In particular,req.on('end')will not happen at all beforehandle.shutdown().AndreasMadsen commentedon May 24, 2017
@refack was this issue solved? I don't remember.
refack commentedon May 24, 2017
I think someone somewhere said something about #12854 might solve this... 🤔
Anyway I did not see it flake in a while.
Running another stress https://ci.nodejs.org/job/node-stress-single-test/nodes=win10/1232/
AndreasMadsen commentedon May 28, 2017
I think the script path was spelled wrong, rerunning: https://ci.nodejs.org/job/node-stress-single-test/1240/
refack commentedon May 29, 2017
✔️ More rigorous stress (-j 16 parallel/test-async-wrap-getasyncid X 100): https://ci.nodejs.org/job/node-stress-single-test/1242/nodes=win10/
33 remaining items
misterdjules commentedon Jul 25, 2017
Fixed by 2da1af0.
test: fix test-async-wrap-getasyncid flakyness
test: fix test-async-wrap-getasyncid flakyness
refack commentedon Oct 7, 2017
Windows VS2017 is back.
https://ci.nodejs.org/job/node-test-binary-windows/11616/COMPILED_BY=vs2017,RUNNER=win2016,RUN_SUBSET=2/console
refack commentedon Oct 11, 2017
And ARM:
https://ci.nodejs.org/job/node-test-binary-arm/10781/RUN_SUBSET=1,label=pi2-raspbian-wheezy/console
misterdjules commentedon Oct 11, 2017
@refack I'm thinking that it might be beneficial to open separate issues for these 2 new occurrences. The reason is that the windows failure is a crash, and so seems like a different problem than the original issue.
The failure on ARM seems more similar to the original issue, but it's still different (2 actual calls vs 0 actual call in the original issue), and so the cause might be different.
Being able to discuss these separate problems in separate issues could help make discussions less confusing.