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
FailedToOpenSocket: Was there a typo in the url or port? #3327
Comments
I've since discovered this error is happening when the process runs out of open files (sockets):
|
@wavded Bun was leaking file descriptors ins a couple important places 3 weeks ago which has since been fixed, so it's likely the underlying cause of this issue is fixed. By default, |
Thx for the update @Jarred-Sumner , I will give the latest version a try and report back my findings. May be a few days to get some data. |
@Jarred-Sumner So far I'm seeing roughly the same FD increases for TCP against |
Just another update on this. Running 0.8.1. I still have the same issue. However, if I set |
Looks similar to the issue I am experiencing in this ticket: |
Confirmed this issue. Closed connections are not removed and stay in the Note: Setting |
I've been debugging this issue for a while using a simple loop with fetch requests to http://127.0.0.1:8080 Here a pooled socket is pushed to pending_sockets. If I change the The port from the pooled socket (even where it is put into the HiveArray at live 593) is always 43690. When looking at the pooled socket using a debugger, I get this:
I'm getting a bit stuck here, tough. Hope this info could be useful to someone. |
Maybe our limit here is too high. Or we need to check if the socket has errors first |
Hi there, I have that same issue when running the bun test command: FailedToOpenSocket: Was there a typo in the url or port? |
Bro, the same happens when ussing Google's recaptcha ( |
We are using |
-v 1.0.18, same here:
|
I am getting this error when the domain can not be reached, and using |
Still happening |
@Jarred-Sumner I'm still getting this error when trying to use gcp packages (specifically @google-cloud/pubsub in this case) in 1.0.27 canary |
sorry i tried it on a real linux machine and everything worked, then i went back to wsl where i was coding before and it suddenly worked there too, so i take everything back it's not easily reproducible and idk if this comment has anything valuable, i did only come across this issue with IPv6 tho |
Happens with openai package. Unlike other cases mentioned here, where it works for some time and then stops, for me it errors from the very start without working once. |
Getting this with network connection in general (outer web or s3) when trying to open a dozen concurrent requests, bin 1.0.30 |
Same issue here. In my case when a local mock server abruptly terminates: the socket goes from ESTABLISHED to CLOSE_WAIT and stays there. |
Unfortunately, I have the same problem with Bun within a Docker container. |
I am using version 1.0.31
package "telegraf" (https://github.com/telegraf/telegraf) running on bun failed with message:
I will wait for updates when it would be fixed. Bun is so unstable 🙄 |
v1.0.30 was a failure. Now I'm trying v1.0.33 |
v1.0.33 was a failure. Now I'm trying v1.0.36 |
v1.0.36 was a failure. Now I'm trying v1.1.2 |
v1.1.2 was a failure. Now I'm trying v1.1.3 |
I'm not waiting for the next failure. I'll try v1.1.4 straight away and keep you up to date. |
Unfortunately, I had to cancel the long-term test because I had to make changes to the code. |
Ran into this exact same issue in v1.1.2. I'm going to give v1.1.7 a go and if it happens again I'll be switching to axios. |
Same issue on v1.1.7. |
Just for reference: |
I have the same issue with Windows 10. Bun version: 1.1.8 |
What version of Bun is running?
0.6.8
What platform is your computer?
Linux 5.19.0-43-generic x86_64 x86_64
What steps can reproduce the bug?
We have this bit of code that will work for a few days without issues and then will start to throw
FailedToOpenSocket: Was there a typo in the url or port?
errors and will not recover unless we restart the Bun server, then it will proceed to work for a few days and the cycle repeats:Note the fetch URL never changes, it almost is like the URL is deemed bad at some point (perhaps for a legit reason) but then it is never allowed to recover, if that makes sense?
Unfortunately, there isn't any reliable way to reproduce this in my testing, but it reliably does not recover once we hit our first error.
Error reference:
bun/src/bun.js/webcore/response.zig
Line 783 in dc06cac
What is the expected behavior?
The
fetch
call should be able to recover and keep working even if URL fails at some point.What do you see instead?
"FailedToOpenSocket: Was there a typo in the url or port?" error for every request after initial failure until the Bun program is restarted.
Additional information
No response
The text was updated successfully, but these errors were encountered: