axios/fetch stalls program

[callumok2004]

What version of Bun is running?

Tried on 1.0.2 and 1.0.3+25aa51dfc4976d1477d2714e5742393f190dc39f

What platform is your computer?

Linux 5.4.0-155-generic x86_64 x86_64

What steps can reproduce the bug?

On WSL, everything seems to work just fine, but when I use my linux server, this does not work with bun, with with node everything runs just fine.

export const DefaultOptions = {
  http: {
    api: "https://discord.com/api",
    version: "10"
  }
};

export const Endpoints = {
  botGateway: "/gateway/bot"
};
//
export async function fetchGatewayInformation(token: string, guildsPerShard = 1000) {
  if (!token) throw new Error("DISCORD_TOKEN_MISSING");

  console.log("Fetching gateway information..."); // This logs
  const data = await fetch(`${DefaultOptions.http.api}/v${DefaultOptions.http.version}${Endpoints.botGateway}`, {
    headers: { Authorization: `Bot ${token.replace(/^Bot\s*/i, "")}`, "Accept-Encoding": "gzip,deflate,compress" }
  }).then(res => res.json());
  console.log("Fetched gateway information."); // This does not log.

  return {
    shards: Math.ceil((data.shards * 1000) / guildsPerShard),
    session_start_limit: data.session_start_limit
  };
}

I am also seeing this in my console which suggests the request was successful.

While it halts on the request, memory usage quickly increases until it eventually reaches the memory limit

What is the expected behavior?

Expecting a response, and for the code to continue as normal

What do you see instead?

The code halts when making fetch/axios requests

Additional information

I am unsure if this is something I am doing wrong myself, or an issue with bun, but I believe it could be bun as running the same code on node works as expected. It's also weird how it works fine on WSL but not on the server

[Electroid]

Sorry that is happening, we'll take a look.

[callumok2004]

Adding this screenshot to show what happens between WSL and linux server, tested on latest release

[akoenig]

I can also confirm (1.0.3) that performing multiple fetch requests leads to a stalled process. The first request is successful, but the next (same) request never resolves.

[Jarred-Sumner]

I can also confirm (1.0.3) that performing multiple fetch requests leads to a stalled process. The first request is successful, but the next (same) request never resolves.

Can you try in canary? bun upgrade --canary

We made some changes to something related to this

[callumok2004]

I can also confirm (1.0.3) that performing multiple fetch requests leads to a stalled process. The first request is successful, but the next (same) request never resolves.

Can you try in canary? bun upgrade --canary

We made some changes to something related to this

Hey, just tested this and sadly I am not seeing any difference

[akoenig]

@Jarred-Sumner, tested with the current canary and it is the same problem. Can break it down a little bit. Looks like it only fails when communicating with a private IP address (e.g. 10.12.0.50 / "Class A"). Hope that helps in any way :)

[akoenig]

@Jarred-Sumner One addition: Not sure if it is related to private IP addresses anymore. When performing the request via curl, I can see that the server closes the connection before the actual response was fully consumed. The curl -v looks like:

"timestamp": 1234567 }
* Closing connection 0
]}%

Somehow processing the response fails when there was a "connection closed" event before. It doesn't happen when I curl a HTTP server where the Connection #0 to host x.x.x.x left intact. Such a request also works in the bun fetch implementation.

Edit: Gone back in the version history and it looks like it is a "regression" between 0.8.1...1.0.0 as 0.8.1 works as expected.

[zomchak-code]

Related to #7260

[hoskin]

+1, this is making it impossible to use the popular twilio library.

[terminal-ator]

+1, this is making it impossible to use the popular twilio library.

Hey, has there been any solution to this?

[github-actions]

Hello @callumok2004. Please provide a minimal reproduction using a GitHub repository, Replit, CodeSandbox, or provide a bulleted list of commands to run that reproduce this issue. Issues marked with needs repro will be closed if they have no activity within 3 days.