null is not an object (evaluating 'http')

[garage44]

What version of Bun is running?

1.2.8

What platform is your computer?

Linux 6.5.0-valve23-1-neptune-65-g385b5e207ae2 x86_64 unknown

What steps can reproduce the bug?

I made a websocket server with WS. Connecting a client produces the following error from 1.2.6 - 1.2.8:

471 | function abortHandshake(response, code, message, headers) {
472 |   message = message || http.STATUS_CODES[code], headers = {
473 |     Connection: "close",
474 |     "Content-Type": "text/html",
475 |     "Content-Length": @Buffer.byteLength(message),
476 |   }, response.writeHead(code, headers), response.write(message), response.end();
                   ^
TypeError: null is not an object (evaluating 'http')
      at abortHandshake (ws:476:14)
      at completeUpgrade (ws:809:21)
      at handleUpgrade (ws:859:25)
      at <anonymous> (ws:728:27)
      at emit (node:events:95:22)
      at onNodeHTTPRequest (node:http:563:24)
[2025-04-08T17:33:31.838Z] [INFO] GET /favicon.ico 200 3ms
[2025-04-08T17:33:31.855Z] [INFO] GET /api/context 200 2ms

Maybe related to the node:http rewrite?

What is the expected behavior?

Websocket client is connected to the WS server without exception

What do you see instead?

The connection process hangs, after which the exception is produced after a short while.

Additional information

I did a quick try to port the application to Bun.serve. Maybe I'll retry this later when I got it stable with WS :-)

[alexandre-lavoie]

Additional info for this:

Issue appears to be raised at: https://github.com/oven-sh/bun/blob/main/src/js/thirdparty/ws.js#L658

Looking up the stacktrace, it appears that socket._httpMessage would be null: https://github.com/oven-sh/bun/blob/main/src/js/thirdparty/ws.js#L1234

I think this would be a test for this: https://github.com/oven-sh/bun/blob/main/test/js/web/websocket/websocket-server-echo.mjs

Will give it a try and see if I can reproduce.

[alexandre-lavoie]

Test case works on my end: Linux 6.13.8-arch1-1 x86_64 unknown.

If it's not sensitive code, I think seeing your setup for client and server would be very valuable. I feel the client might be dropping the connection during the handshake which somehow leads to this value being null. This should really be addressed though because there is no way for a dev to try-catch it given it's internal code.

I don't think this is a factor but SteamOS is in use here (really cool to see that).

[garage44]

Hi @alexandre-lavoie,

If it's not sensitive code, I think seeing your setup for client and server would be very valuable. I feel the client might be dropping the connection during the handshake which somehow leads to this value being null. This should really be addressed though because there is no way for a dev to try-catch it given it's internal code.

No problem! It is part of an opensource project. The relevant files are:

https://github.com/garage44/expressio/blob/main/src/components/main/main.tsx#L26
https://github.com/garage44/common/blob/main/lib/ws-client.ts
https://github.com/garage44/expressio/blob/main/service.ts#L223
https://github.com/garage44/common/blob/main/lib/ws-server.ts

I just moved the code from a mono repo back to several separate ones. The setup is a bit broken and hard to test at the moment.

I don't think this is a factor but SteamOS is in use here (really cool to see that).

It is more of a hobby laptop than a gaming device to me :)

[alexandre-lavoie]

Hi @garage44,

I had a look at your repos and seems your main issue is package.json not correctly exporting files. I manually copied the repos in my node_modules and it works. I opened some issues on your projects that should guide you towards a fix for those.

I managed to reproduce the issue with your repo so I confirm there is an issue.

I carved out the "core" client/server (WebSocketClient and WebSocketServer) from linked code. I ran them both locally and on web and they connect without issue. Therefore I suspect there is an issue with a middleware.

I'll continue investigating.

[garage44]

Sorry for the late response and the difficult to reproduce setup I described. I needed some time to get the whole repo/workspace setup on Github working again. In order to reproduce the same issue you tracked down, the steps are a bit simpler now:

# Latest working version
curl -fsSL https://bun.sh/install | bash -s "bun-v1.2.4"
git clone --recurse-submodules --remote-submodules git@github.com:garage44/workspace.git
cd workspace
bun i
cd packages/expressio
bun run dev
# http://localhost:3030

Update, and check again:

bun upgrade
bun run dev