I noticed a strange issue while using the contentful package after upgrading Bun. After some testing, I discovered the issue only occurs on Bun versions after 1.1.26 (last working version).
The issue is that the Contentful API client seemingly attempts to connect to their API URL using a combination of https:// and port 80. This causes the connection to fail.
I originally reported this in the Contentful Discord server before I found the relation to Bun. Therefore, I suspect this may be a Node-compatibility related issue.
Contentful uses Axios under the hood for communication.
I haven't yet found the exact piece of code causing this, but I would assume it has something to do with the detection of which protocol to use and how to match up port 80 or 443 to that protocol. I will pop back with anything I find, but maybe someone more familiar with the related changes in v1.1.27 already has an inkling? 😅
Reproduction
While using an affected Bun version (such as latest, v1.1.29 atm), create a new project and bun add contentful
In the index.ts file, add the following:
import { createClient } from "contentful";
const client = createClient({
space: "example",
accessToken: "nothing",
retryLimit: 1, // just to skip retries for 30 seconds
});
await client.getEntries();
Run bun . on the file. The output will look something like this:
% bun .
[warning] Connection error occurred. Waiting for 2035 ms before retrying...
ConnectionRefused: Unable to connect. Is the computer able to access the url?
ConnectionRefused: Unable to connect. Is the computer able to access the url?
path: "https://cdn.contentful.com:80/spaces/example/environments/master/entries"
Bun v1.1.29 (macOS arm64)
What is the expected behavior?
I expect the API client to connect as intended, and as it did previously in version 1.1.26 or prior. The protocol should be https:// and the port should be 443.
What do you see instead?
The API client seemingly attempts to connect to their API URL using a combination of https:// and port 80. This causes the connection to fail.
Additional information
I tested several versions of Contenful's package. Both older and newer versions worked before the Bun upgrade, and both stopped working after.
This also likely has nothing to do with OS, as it also occurs on Linux/ARM (although I suppose I haven't tried an x86 OS)
What version of Bun is running?
1.1.29+6d43b3662
What platform is your computer?
Darwin 23.6.0 arm64 arm
What steps can reproduce the bug?
I noticed a strange issue while using the contentful package after upgrading Bun. After some testing, I discovered the issue only occurs on Bun versions after 1.1.26 (last working version).
The issue is that the Contentful API client seemingly attempts to connect to their API URL using a combination of
https://
and port 80. This causes the connection to fail.I originally reported this in the Contentful Discord server before I found the relation to Bun. Therefore, I suspect this may be a Node-compatibility related issue.
Contentful uses Axios under the hood for communication.
I haven't yet found the exact piece of code causing this, but I would assume it has something to do with the detection of which protocol to use and how to match up port 80 or 443 to that protocol. I will pop back with anything I find, but maybe someone more familiar with the related changes in v1.1.27 already has an inkling? 😅
Reproduction
While using an affected Bun version (such as latest, v1.1.29 atm), create a new project and
bun add contentful
In the
index.ts
file, add the following:Run
bun .
on the file. The output will look something like this:What is the expected behavior?
I expect the API client to connect as intended, and as it did previously in version 1.1.26 or prior. The protocol should be
https://
and the port should be443
.What do you see instead?
The API client seemingly attempts to connect to their API URL using a combination of
https://
and port80
. This causes the connection to fail.Additional information
I tested several versions of Contenful's package. Both older and newer versions worked before the Bun upgrade, and both stopped working after.
This also likely has nothing to do with OS, as it also occurs on Linux/ARM (although I suppose I haven't tried an x86 OS)