-
Notifications
You must be signed in to change notification settings - Fork 570
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
: send
callbacks are not all called if multiple messages are sent rapidly
#698
Comments
jonathanperret
added a commit
to jonathanperret/engine.io
that referenced
this issue
Feb 23, 2024
jonathanperret
added a commit
to jonathanperret/engine.io
that referenced
this issue
Feb 23, 2024
jonathanperret
added a commit
to jonathanperret/engine.io
that referenced
this issue
Feb 23, 2024
jonathanperret
added a commit
to jonathanperret/engine.io
that referenced
this issue
Feb 23, 2024
This was referenced Feb 23, 2024
jonathanperret
changed the title
Feb 23, 2024
websocket
: send
callbacks are not all called if multiple packets are sent rapidlywebsocket
: send
callbacks are not all called if multiple messages are sent rapidly
darrachequesne
pushed a commit
that referenced
this issue
Jun 13, 2024
With the `websocket` transport, the callbacks which indicate that the packets are actually written were not properly called. Example: ```js socket.send("hello", () => { // the message has been written to the underlying transport }); ``` The bug was caused by the `websocket` transport (and `webtransport` as well) having its `supportsFraming` property set to `true`, despite having been changed in [1] to emit a single `drain` event for each batch of messages written to the transport like the `polling` transport always did. Note that although [1] is partially reverted in [2], the new `drain` event behavior is preserved as called out in that commit's message. The `supportsFraming` attribute was introduced in [3] (amended by [4]) as a way to distinguish transports that emit one `drain` per message from those that emit one `drain` per batch. Since the delivery of `send` callbacks depends on matching `drain` events with `transport.send` calls, that distinction is vital to correct behavior. However, now that all transports have converged to "one `drain` per batch" behavior, this `supportsFraming` property can be retired (and the code for calling callbacks simplified). [1]: #618 [2]: a65a047 [3]: #130 [4]: #132 Related: #698
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When using the
websocket
transport, ifsocket.send()
is called multiple times in the same tick with a callback provided, some of the callbacks may not be called even though the messages were sent.To Reproduce
Engine.IO server version:
6.5.4
Server
Engine.IO client version:
6.5.0
Client
Expected behavior
The server above should log:
Instead it logs:
It does log
callback 3 called
after about 25 seconds, andcallback 4 called
25 seconds later — enabling debug logs shows thatping
packets are triggering those late callbacks.The client logs that the messages are all received immediately.
Platform:
Additional context
There is an existing test that is supposed to check this scenario. However it does not expose this bug, because it does not specify a transport and defaults to
polling
, which also makes it redundant with the next test. That first test also only sends two messages, when the test program above shows that only the third and further callbacks are delayed.The text was updated successfully, but these errors were encountered: