-
Notifications
You must be signed in to change notification settings - Fork 669
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
Sockets hanging with node16 #7097
Comments
Hi @andrzej-kodify Thank you for the shared example. I've reproduced the issue. |
In testcafe there is an issue with node 16 which leads to the first test to fail. DevExpress/testcafe#7097
Hello, I experience the same issue with pending requests, when I create a request to non-existing domain, so the DNS fails to resolve the domain name, and the error is not passed to the client. |
Thank you for the additional information! We increased the frequency level for this issue, which will give it higher priority during our future planning. |
Can someone please work on this?! We are stuck with super old Testcafé since this bug prevents us from upgrading node version. We have this problem with node 14 as well 😢 |
Hi @cattermo, This issue may be fixed in the latest version of TestCafe ( |
Ok, so we have upgraded now since a couple of weeks back. Problem is, we are having so many intermittent errors where requests are just stuck and causing "Failed to fetch" errors, similar to when we tried last time to upgrade, found this bug reported, and decided to downgrade again. The "intermittent" part means that different random tests will have this error almost every test run but by using quarantine mode we can be lucky and have all tests pass. Findings from trying to investigate this issue:
Other info:
|
Hi @cattermo, Thank you for checking tests in the new TestCafe version. // Command-line
testcafe chrome tests --experimental-proxyless
// Programmatic
const testcafe = await createTestCafe({ experimentalProxyless: true });
// Configuration file
{
"experimentalProxyless": "true"
} Note that at present it is an experimental mode. |
FYI after upgrading to 2.2.0 I learned about Update 2023-01-05: when I was able to reproduce this consistently, I was on a low-bandwidth mobile tethered connection. Now, with a cable or high bandwidth mobile connection, I can no longer reproduce it. 😿 |
Hello @dcsaszar , Thank you for pointing out the issue to us. |
Hi @miherlosev, yes I tried it, but application's authorization fails in case experimentalProxyless option enabled |
In this case, could you please share an example where the issue can be reproduced? |
Hi, |
This issue was automatically closed because there was no response to our request for more information from the original author. Currently, we don't have enough information to take action. Please reach out to us if you find the necessary information and are able to share it. We are also eager to know if you resolved the issue on your own and can share your findings with everyone. |
We we're testing this last week but had some other issues so could not finalise the testing yet. Please do not close. |
Hello @cattermo , If you manage to reproduce the problematic behavior, feel free to reopen the issue. If you encounter some new problem, please create a separate issue with a reproducible example. |
Hello, |
I reproduced the problematic behavior using the example shared in the original post in the environment with the following configuration:
I will reopen the issue, but currently, we cannot give any estimates on when we will fix it. |
This issue was automatically closed because there was no response to our request for more information from the original author. Currently, we don't have enough information to take action. Please reach out to us if you find the necessary information and are able to share it. We are also eager to know if you resolved the issue on your own and can share your findings with everyone. |
@aleks-pro And there it was automatically closed again 😅 . Can someone re-open and remove the "Need response" label? |
What is your Scenario?
Web app that makes client side fetch to two API endpoints, both on localhost but one is not running, so doesn't accept connections (which is fine, error is handled and app is functional)
Running tests with node v14.x is just fine, after switching to v16 tests start to break after a while
Symptoms observed in chrome network tools are that calls to both API endpoints are in
pending
stateAfter a while of debugging I've noticed that testcafe's behaviour for requests that are supposed to fail (since there's no server listening) is much different in node16 than node14
Looking at network tools:
Node v16
Node v14
As you can see, in node 14 such request fails instantly, as it should. With node 16 the request is
pending
.I cannot prepare a sample that reproduces my exact problem (where after a while both
/api
calls are constantlypending
in subsequent tests) but I'm assuming maybe sockets are not properly closed in my case and just saturate some system limitsWhat is the Current behavior?
Fetch requests that are supposed to fail are
pending
What is the Expected behavior?
Requests should fail immediately if there's no server listening on the other end
What is your public website URL? (or attach your complete example)
https://github.com/andrzej-kodify/testcafe-hanging-sockets
Launch server
Launch tests with node 16
and look in chrome network tools on how failed requests behave. Tests are passing, no JS errors.
Do the same with node 14 - requests fail immediately, and there's a JS error (as fetch exception is not handled)
What is your TestCafe test code?
// https://github.com/andrzej-kodify/testcafe-hanging-sockets
Your complete configuration file
No response
Your complete test report
No response
Screenshots
No response
Steps to Reproduce
TestCafe version
1.19.0
Node.js version
version v14.18.1 runs fine, versions 16+ (e.g. v16.15.1) fail
Command-line arguments
chrome
Browser name(s) and version(s)
Version 102.0.5005.61 (Official Build) (arm64)
Platform(s) and version(s)
macOS 12.4
Other
I've made silly workaround by applying this patch in my actual tests
https://github.com/andrzej-kodify/testcafe-hanging-sockets/blob/main/testcafe-hammerhead%2B24.5.16.patch
The text was updated successfully, but these errors were encountered: