FailedToOpenSocket: Was there a typo in the url or port?

[wavded]

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?

  ...
  let res = new Response()
  try {
    res = await fetch("http://myservice.foo.bar/generate", {
      method: "POST",
      body: JSON.stringify(query),
      headers: {
        accept: "application/json",
        "content-type": "application/json",
      },
    })
    res.headers.set(
      "content-disposition",
      `attachment; filename=${q.name || "output"}.pdf`
    )
  } catch (err: any) {
    throw new HTTPException(400, {message: err.message})
  }
  return res

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: https://github.com/oven-sh/bun/blob/dc06caccaa6bd8fd273e16cff2c2e0c10f32c58e/src/bun.js/webcore/response.zig#L783

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

[wavded]

I've since discovered this error is happening when the process runs out of open files (sockets):

• The response from fetch is being used as the response for the HTTP server. Is this causing a socket to stay open somehow? And if so, how do you write a proxy without causing a socket leak in Bun?

• Is there a way to get a more helpful error when we've ran out of open files?

[Jarred-Sumner]

@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, fetch has keepalive set to true which will keep up to 128 sockets open up to a timeout (64 http, 64 https). This is an important performance optimization for https, but you can disable it with keepalive: false passed to fetch in the 2nd argument.

[wavded]

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.

[wavded]

@Jarred-Sumner So far I'm seeing roughly the same FD increases for TCP against 0.7.1. As of writing this, the process is at 779 TCP sockets open. I am using the defaults for fetch. I do build the project using bun build --compile if that would make any difference. I'm happy to provide any other details that you would find helpful.

[wavded]

Just another update on this. Running 0.8.1. I still have the same issue. However, if I set keepalive: false, the issue goes away. Sockets don't seem to top off at 128 for me with keepalive: true, they just keep growing. I'll roll with keepalive: false for now!

[weyert]

Looks similar to the issue I am experiencing in this ticket: https://github.com/oven-sh/bun/issues/4548

[pmzandbergen]

Confirmed this issue. Closed connections are not removed and stay in the CLOSE_WAIT status forever (until you run out of sockets).

Note: Setting keepalive: false fixes the issue but is of course not the solution.

[cornedor]

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. https://github.com/oven-sh/bun/blob/main/src/http_client_async.zig#L593

If I change the .kind = .unset condition from the iterator to .kind = .set (With the .unset condition in place the iterator will never have any items) a few lines lower, then at line 610 the port comparison will always fail.

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:

{
  http_socket: {socket:0xaaaaaaaaaaaaaaaa}
  port:43690,
  hostname_buf:"\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa",
  hostname_len: "\xaa"}

I'm getting a bit stuck here, tough. Hope this info could be useful to someone.

[Jarred-Sumner]

Maybe our limit here is too high. Or we need to check if the socket has errors first

[lefuncq]

Hi there,

I have that same issue when running the bun test command:

FailedToOpenSocket: Was there a typo in the url or port? path: "https://db:3306/psdb.v1alpha1.Database/Execute" In parallel, Some servers are running on ports 3001, 4001, and 4566 and a MySQL database running on port 3306. I initially thought the db was the issue, but even after stopping every server, database, freeing my ports and even restarting my machine, I keep getting this error. This is really blocking, does anyone have a workaround?

[EduApps-CDG]

Bro, the same happens when ussing Google's recaptcha (@google-cloud/recaptcha-enterprise)

[ArifNawaz36]

We are using axios instead of fetch with Bun. The keepAlive is false by default in the httpAgent, but still we encountered this issue in production. It is a great concern for us as we are running in production. Does anyone have any workaround to resolve it?

[di-sukharev]

-v 1.0.18, same here:

import { Firestore, setLogFunction } from "@google-cloud/firestore";

setLogFunction(console.log);

export const firestore = new Firestore({
  preferRest: true,
});

await firestore.collection("something").doc("anything").set({})

[phtdacosta]

I am getting this error when the domain can not be reached, and using keepalive: false is not fixing it by any means. What could be done @Jarred-Sumner?

[hyoretsu]

Still happening

[TDH55]

@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

[masterflitzer]

FailedToOpenSocket: Was there a typo in the url or port?

~~i think this may be IPv6 related (if not i apologise and will open another issue), because i am getting the exact same error `` when i am fetching with an ipv6 as hostname inside the URL:~~

~~easily reproducable when running the following code in bun repl (the exact same code works in both node and deno)~~

• ~~Hostname (works at least with my testing, maybe bun prefers IPv4 DNS responses, idk): await (await fetch(new URL("https://one.one.one.one/cdn-cgi/trace"))).text()~~
• ~~IPv4 (works): await (await fetch(new URL("https://1.1.1.1/cdn-cgi/trace"))).text()~~
• ~~IPv6 (doesn't work): await (await fetch(new URL("https://[2606:4700:4700::1111]/cdn-cgi/trace"))).text()~~

~~i hope this can be fixed without too much complexity because non-working ipv6 makes bun unusable for me~~

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

[Arctomachine]

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.

[terion-name]

Getting this with network connection in general (outer web or s3) when trying to open a dozen concurrent requests, bin 1.0.30

[hranum]

Same issue here. In my case when a local mock server abruptly terminates: the socket goes from ESTABLISHED to CLOSE_WAIT and stays there.

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

[manazoid]

I am using version 1.0.31

$ bun -v
1.0.31

package "telegraf" (https://github.com/telegraf/telegraf) running on bun failed with message:

FailedToOpenSocket: Was there a typo in the url or port?
 path: "https://api.telegram.org/botTOKEN/getUpdates"

I will wait for updates when it would be fixed. Bun is so unstable 🙄

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

v1.0.30 was a failure. Now I'm trying v1.0.33

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

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

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

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

bun_1  | FailedToOpenSocket: Was there a typo in the url or port?
bun_1  |  path: "http://directus:8055/items/quote_of_the_day/1"

v1.0.36 was a failure. Now I'm trying v1.1.2

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

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

bun_1  | FailedToOpenSocket: Was there a typo in the url or port?
bun_1  |  path: "http://directus:8055/items/quote_of_the_day/1"

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

[gerold-penz]

Unfortunately, I have the same problem with Bun within a Docker container. I have now updated to version 1.0.30. I'll know in a few days whether the problem still exists.

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

bun_1  | FailedToOpenSocket: Was there a typo in the url or port?
bun_1  |  path: "http://directus:8055/items/quote_of_the_day/1"

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.

[gerold-penz]

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.

[kallama]

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.

[kallama]

Same issue on v1.1.7.