Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: WS connection does not work using node 22 #255

Closed
2 tasks done
Pixelycia opened this issue May 6, 2024 · 4 comments
Closed
2 tasks done

Bug: WS connection does not work using node 22 #255

Pixelycia opened this issue May 6, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@Pixelycia
Copy link

Describe the bug

Node 22. When you try to connect to database with ws://localhost:8000/rpc - it throws an error.

(node:60935) [UNDICI-WS] Warning: WebSockets are experimental, expect them to change at any time.
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/event_target:1095
  process.nextTick(() => { throw err; });
                           ^

TypeError: Cannot read properties of null (reading 'buffer')
    at WebSocket.<anonymous> (/Users/.../node_modules/surrealdb.js/src/library/engine.ts:109:14)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:821:20)
    at WebSocket.dispatchEvent (node:internal/event_target:756:26)
    at fireEvent (node:internal/deps/undici/undici:10966:14)
    at websocketMessageReceived (node:internal/deps/undici/undici:10988:7)
    at ByteParser.run (node:internal/deps/undici/undici:11439:17)
    at ByteParser._write (node:internal/deps/undici/undici:11315:14)
    at writeOrBuffer (node:internal/streams/writable:564:12)
    at _write (node:internal/streams/writable:493:10)
    at Writable.write (node:internal/streams/writable:502:10)

Node.js v22.1.0

Node 20. Works as expected.

Steps to reproduce

  1. Use node 22, tested on v22.1.0.
  2. Use code:
const db = new Surreal()
await db.connect("ws://localhost:8000/rpc", {
  namespace: "root",
  database: "root",
})
await db.query(`RETURN time::now()`).then(r => console.log(r))
  1. Observe the error above.

Expected behaviour

Should return similar something like

[ 2024-05-06T15:30:41.867Z ]

SurrealDB version

1.4.2 for macos on aarch64

SurrealDB.js version

1.0.0-beta.5

Contact Details

No response

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Pixelycia Pixelycia added the bug Something isn't working label May 6, 2024
@Dhghomon
Copy link

Dhghomon commented May 8, 2024

@kearfy

@tai-kun
Copy link
Contributor

tai-kun commented May 10, 2024

I have the same issue.

This is likely not a bug in surrealdb.js, but rather a bug in undici or a non-compliance with the WebSocket specification (RFC 6455) by other WebSocket clients.

The WebSocket class, which was added to the global namespace without a flag in Node.js v22, is implemented within undici and seems to behave slightly differently from other WebSocket clients (Deno and ws).

Specifically, there is a discrepancy in how chunked data sent from the WebSocket server is interpreted. undici does not reset the opcode unless chunked data containing a payload is sent. This means that when a ping response (<Buffer 89 00>) is received from the WebSocket server, undici remembers that the opcode is 9 (i.e. "Ping Frame") and ultimately drops the payload of subsequent chunked data. This ping communication is performed by the WebSocket to maintain the connection, independently of surrealdb.js's Pinger.

To resolve this issue, it may be necessary to make changes to the implementation of undici. I'm using Node.js v22.1.0 and have checked the behavior with undici v6.13.0, but I have also obtained the same results with the latest version, v6.16.0.

However, the WebSocket specification is quite complex, and I am not entirely sure if this is a bug in undici. It is also possible that undici's WebSocket implementation is correct and other implementations are not compliant with the specification.

@kearfy
Copy link
Member

kearfy commented May 13, 2024

Hey everyone! I wasn't able to reproduce this issue last week, turns out that nvm was playing with me 😅

I was however able to reproduce it today, and it turns out that the MessageEvent class does not pass back a required data property, according the MDN: https://developer.mozilla.org/en-US/docs/Web/API/MessageEvent/data

I'm quite positive that this is an issue in NodeJS

@kearfy
Copy link
Member

kearfy commented Jun 11, 2024

Hey everyone! I noticed that NodeJS a short while ago, merged in an autobahn test, so decided to give NodeJS 22 another shot. All seems well with NodeJS v22.3.0!

@kearfy kearfy closed this as completed Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants