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

WebSocket client reliability #6686

Closed
Electroid opened this issue Oct 24, 2023 · 9 comments · Fixed by #7371
Closed

WebSocket client reliability #6686

Electroid opened this issue Oct 24, 2023 · 9 comments · Fixed by #7371
Labels
tracking An umbrella issue for tracking big features

Comments

@Electroid
Copy link
Contributor

There are various issues with Bun's WebSocket client that have to do with parsing frames properly. We need to add the Autobahn to our tests and start fixing the bugs in websocket_http_client.zig.

Note: this is not to be confused with Bun's WebSocket server, which is implemented by uWebSockets which uses the Autobahn test suite.

@DeveloperHarris
Copy link

Unsure, but is this also related?

#5588

@tscpp
Copy link

tscpp commented Nov 12, 2023

Is this something that is planned to be fixed in the near future?

@Mwni
Copy link

Mwni commented Nov 18, 2023

This makes it impossible for me to adopt bun at the moment. An approximate ETA would be very appreciated.

@LucyEgan
Copy link

Yeh its definitely a unexpected partial blocker for us, but there is https://github.com/Vexcited/tcp-websocket that might be worth exploring as a work around

@Electroid
Copy link
Contributor Author

You can test these fixes right now if you run bun upgrade --canary. It will be available in Bun v1.0.15, which will come out today or tomorrow.

@wottpal
Copy link

wottpal commented Dec 1, 2023

You guys rock! Looking forward to try this!

@rori4
Copy link

rori4 commented Dec 20, 2023

I can confirm the wevm/viem#1342 and #6189 are no longer an issue with the latest version. Great job guys!

@philosofonusus
Copy link

still an issue for me when using ethers v6 and bun v1.0.29 I just subscribed to Mempool like this:

wsProvider.on("pending", (tx) => {
  wsProvider.getTransaction(tx).then(async (transaction) => {
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-websocket.js:47:13
249 |     /**
250 |      *  Sub-classes **must** call this with messages received over their
251 |      *  transport to be processed and dispatched.
252 |      */
253 |     async _processMessage(message) {
254 |         const result = (JSON.parse(message));
                              ^
SyntaxError: JSON Parse error: Unexpected identifier "too"
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-socket.js:254:25
      at _processMessage (/Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-socket.js:253:27)
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-websocket.js:47:13

@Electroid
Copy link
Contributor Author

still an issue for me when using ethers v6 and bun v1.0.29 I just subscribed to Mempool like this:

wsProvider.on("pending", (tx) => {
  wsProvider.getTransaction(tx).then(async (transaction) => {
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-websocket.js:47:13
249 |     /**
250 |      *  Sub-classes **must** call this with messages received over their
251 |      *  transport to be processed and dispatched.
252 |      */
253 |     async _processMessage(message) {
254 |         const result = (JSON.parse(message));
                              ^
SyntaxError: JSON Parse error: Unexpected identifier "too"
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-socket.js:254:25
      at _processMessage (/Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-socket.js:253:27)
      at /Users/tentacles/Projects/stealth_ff/node_modules/ethers/lib.esm/providers/provider-websocket.js:47:13

It's possible this could be another bug, could you open another issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracking An umbrella issue for tracking big features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants