A WebSocket whose outgoing buffer never drains is now detected after 60 seconds instead of hanging.
What's wrong with this entry?
The WebSocket transport gained a 60 second send stall timeout (sendStallTimeoutMs: 60000) plus receive-side high and low watermarks and a queued-download byte report. A socket whose outgoing buffer never drains is now identified rather than waiting forever.
- When the send path pauses to wait for a drain, it records how much was buffered and when the wait started, which is what the timeout is measured against.
sendPauseAfterPendingBytesdefaults to 0.- No gate; this applies to all WebSocket traffic.
sendStallTimeoutMs
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.225
Streaming read index no longer skips messages
Both mention transport
-
v2.1.225
Unknown control messages complete their command lifecycle
Both mention transport
-
v2.1.234
The stdin transport now answers the remote-transport questions
Both mention transport