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

wavded commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

pmzandbergen commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

lefuncq commented 12 months ago

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 commented 11 months ago

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

ArifNawaz36 commented 11 months ago

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 commented 10 months ago

-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 commented 9 months ago

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 commented 9 months ago

Still happening

TDH55 commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

hranum commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

Same issue on v1.1.7.

Megajin commented 6 months ago

Just for reference: I have tried Bun 1.1.8 with fetch and axios. Both gave me the same error in production, even with keepAlive:false. However the interesting part ist, the production build (single-executable) works with fetch or axios on a fresh Windows 11 VM and as well as on a ZorinOS VM (Ubuntu based). The only OS which gives me the Error: FailedToOpenSocket: Was there a typo in the url or port? is a Windows Server 2022 . Maybe that helps to track down the problem.

Odonno commented 6 months ago

Just for reference: I have tried Bun 1.1.8 with fetch and axios. Both gave me the same error in production, even with keepAlive:false. However the interesting part ist, the production build (single-executable) works with fetch or axios on a fresh Windows 11 VM and as well as on a ZorinOS VM (Ubuntu based). The only OS which gives me the Error: FailedToOpenSocket: Was there a typo in the url or port? is a Windows Server 2022 . Maybe that helps to track down the problem.

I have the same issue with Windows 10.

Bun version: 1.1.8

Megajin commented 6 months ago

Just for reference: I have tried Bun 1.1.8 with fetch and axios. Both gave me the same error in production, even with keepAlive:false. However the interesting part ist, the production build (single-executable) works with fetch or axios on a fresh Windows 11 VM and as well as on a ZorinOS VM (Ubuntu based). The only OS which gives me the Error: FailedToOpenSocket: Was there a typo in the url or port? is a Windows Server 2022 . Maybe that helps to track down the problem.

I have some more informations in addition to my post above: The Windows-Server which runs into the mentioned error has a proxy setup! No username or password needed. But it is a http proxy used as well for https requests. I was able to reproduce a timeout with axios as well in this kind of setup. Using a http proxy for https requests seems to be prone to errors.

Setting the proxy like this:

await fetch("https://example.com", {
  // The URL of the proxy server
  proxy: "http://proxy.example.com:8080",
});

resulted in an error.

Setting the envs like this:

HTTPS_PROXY=http://proxy.example.com:8080
HTTP_PROXY=http://proxy.example.com:8080

All lead to the same error.

At this point I am pretty sure there is something going on with http to https.

My temp solution: I have used the neon to create a NodeJS API with the Rust Cargo package: ureq to use for my requests.

danielgwilson commented 5 months ago

Same (?) issue, MacOS on bun v1.1.9 when attempting to use @google-cloud/logging + winston

343 |                         'ECONNREFUSED',
344 |                     ].includes(err.code))) {
345 |                 let code = 'UNKNOWN';
346 |                 if (err.code)
347 |                     code = err.code;
348 |                 process.emitWarning(`received unexpected error = ${err.message} code = ${code}`, 'MetadataLookupWarning');
                      ^
warn: received unexpected error = Was there a typo in the url or port? code = FailedToOpenSocket
      at /Users/username/.../node_modules/gcp-metadata/build/src/index.js:348:17

Jarred-Sumner commented 5 months ago

This is fixed in the canary build of Bun.

Relevant PRs:

The fix will go out in Bun v1.1.13 which releases Wednesday.

To try it before that:

bun upgrade --canary

There may still be issues when using proxies, but please open a separate issue for that.

oven-sh / bun