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

Bun.connect on socket fails on large message, where node's net works #16076

Closed
dlants opened this issue Dec 31, 2024 · 1 comment
Closed

Bun.connect on socket fails on large message, where node's net works #16076

dlants opened this issue Dec 31, 2024 · 1 comment
Labels
bug Something isn't working needs triage

Comments

@dlants
Copy link

dlants commented Dec 31, 2024

What version of Bun is running?

1.1.42+50eec0025

What platform is your computer?

MacOs 14.6.1 (23G93)

What steps can reproduce the bug?

I tried to narrow things down here: https://github.com/dlants/neovim-mini-repro

initially I thought the issue was on neovim's side, but I think it's in Bun.connect on the socket.

As the repo is configured, you can see that:

  • the small file is sent
  • neovim receives it and updates the buffer
  • the large file is sent
  • neovim does not receive it
  • no subsequent messages sent to neovim receive replies

If you swap the script to node instead:

  • rm -rf node_modules
  • npm install
  • uncomment the jobstart for node and comment out the jobstart for bun

Then you can see the large file makes it into neovim.

I'd be happy to try and reduce it more, but I'm not super familiar with sockets so I'm not sure what to look for / what to sub out neovim for?

What is the expected behavior?

Should work the same in node and bun.

What do you see instead?

Works in node, does not work in bun.

Additional information

No response

@Jarred-Sumner
Copy link
Collaborator

Jarred-Sumner commented Dec 31, 2024

socket.write returns the number of bytes written and doesn't buffer. That means if you write a large amount of data, the network might not send all of it, and you have to retry the unsent data when the drain callback is called. This buffering behavior is how it works in the system APIs on posix/windows.

This is very much a footgun, and we need to make this clearer in the documentation or have a way to buffer this automatically (outside of using node:net), because you're not the first person who thought this was a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs triage
Projects
None yet
Development

No branches or pull requests

2 participants