Fix websocket
and webtransport
multipart callbacks (#698)
#699
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The kind of change this PR does introduce
Current behaviour
When using the
websocket
transport, somesend
callbacks are not called. See #698, and the tests added in the first commit of this PR. Thewebtransport
transport was also found to have the same bug when testing.New behaviour
All
send
callbacks are now called.Also, the type for the
callback
argument tosend()
was enriched to reflect the fact that the transport is passed (as it always has been) as its first argument. This does change the types visible publicly, but TypeScript type compatibility rules should make this a non-breaking change (i.e. it's still OK to pass a callback expecting no arguments).Other information
The bug was caused by the
websocket
transport (andwebtransport
as well) having itssupportsFraming
property set totrue
, despite having been changed in #618 to emit a singledrain
event for each batch of messages written to the transport like thepolling
transport always did. Note that although #618 is partially reverted in a65a047, the newdrain
event behavior is preserved as called out in that commit's message.The
supportsFraming
attribute was introduced in #130 (amended by #132) as a way to distinguish transports that emit onedrain
per message from those that emit onedrain
per batch. Since the delivery ofsend
callbacks depends on matchingdrain
events withtransport.send
calls, that distinction is vital to correct behavior.However, now that all transports have converged to "one
drain
per batch" behavior, thissupportsFraming
property can be retired (and the code for calling callbacks simplified), and this is the refactoring that the last commit of this PR proposes. This is technically a breaking change sincesupportsFraming
was exposed in the TypeScript types ofengine.io
, but as far as I can tell it was never documented.