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
{{ message }}
Repository navigation
Investigate flaky parallel/test-async-hooks-http-parser-destroy on OS X #28112
The test duration in failed cases seems to be significant longer as in the pass case. Not sure if duration_ms: 120.95 is really in milli seconds - as a wild guess I would say it's in sec and therefore 2 minutes which would match the default http timeout used by node as far as I know.
I have no access to OS X so hard for me to work on this.
The test duration in failed cases seems to be significant longer as in the pass case. Not sure if duration_ms: 120.95 is really in milli seconds - as a wild guess I would say it's in sec and therefore 2 minutes which would match the default http timeout used by node as far as I know.
I have no access to OS X so hard for me to work on this.
duraion_ms is unfortunate, but it's a tap thing so we can't/shouldn't change it. It is duration in seconds.
It fails at 120 seconds because that's the timeout duration in the test runner.
So it gets caught in a deadlock or infinite loop or waiting for an event that never actually fires or (unlikely but possible) maybe just takes too darned long to run and would complete if it had more time or...
Hmm, maybe add some more counters, e.g. one for HTTPINCOMINGMESSAGE and HTTPCLIENTREQUEST, one for client responses and then assert on them first before the diff of the list to get some hint what is hanging.
Or hope that some OS X users gives a try to reproduce this locally and debug.
Has #28253 fixed the flaky parallel/test-async-hooks-http-parser-destroy on OS X? Don't know how to query CI statistics.
Used ncu-ci from node-core-utils to check and couldn't find any async-hooks test failures other than test-statwatcher.js. So I think we can conclude that this isn't a problem and plan to re-open if that's wrong and someone notices it poppingup again.
Activity
Flarna commentedon Jun 13, 2019
The test duration in failed cases seems to be significant longer as in the pass case. Not sure if
duration_ms: 120.95is really in milli seconds - as a wild guess I would say it's in sec and therefore 2 minutes which would match the default http timeout used by node as far as I know.I have no access to OS X so hard for me to work on this.
Trott commentedon Jun 13, 2019
duraion_msis unfortunate, but it's atapthing so we can't/shouldn't change it. It is duration in seconds.It fails at 120 seconds because that's the timeout duration in the test runner.
So it gets caught in a deadlock or infinite loop or waiting for an event that never actually fires or (unlikely but possible) maybe just takes too darned long to run and would complete if it had more time or...
Flarna commentedon Jun 13, 2019
Hmm, maybe add some more counters, e.g. one for
HTTPINCOMINGMESSAGEandHTTPCLIENTREQUEST, one for client responses and then assert on them first before the diff of the list to get some hint what is hanging.Or hope that some OS X users gives a try to reproduce this locally and debug.
sam-github commentedon Jun 13, 2019
@Flarna Are you willing to PR that change, ☝️ ? It would be very helpful if you have time to start looking into this.
Flarna commentedon Jun 13, 2019
Sure, will take a look in a free slot during next days.
created #28253
Flarna commentedon Jun 28, 2019
Is this still valid? PR is open since quite a while now...
test: improve test-async-hooks-http-parser-destroy
lpinca commentedon Jul 13, 2019
I can't reproduce locally but I'm on macOS 10.14 not 10.11.
test: improve test-async-hooks-http-parser-destroy
test: improve test-async-hooks-http-parser-destroy
Flarna commentedon Sep 14, 2019
Has #28253 fixed the flaky parallel/test-async-hooks-http-parser-destroy on OS X? Don't know how to query CI statistics.
Trott commentedon Sep 15, 2019
Used
ncu-cifromnode-core-utilsto check and couldn't find anyasync-hookstest failures other thantest-statwatcher.js. So I think we can conclude that this isn't a problem and plan to re-open if that's wrong and someone notices it poppingup again.Thanks, @Flarna!