{"version":"2.1.248","anchor":"stalled-websocket-sends-are-now-detected-instead-of-hanging","canonical_anchor":"stalled-websocket-sends-are-now-detected-instead-of-hanging","heading":"Stalled WebSocket sends are now detected instead of hanging","tier":"notice","area":"Session Transport","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/stalled-websocket-sends-are-now-detected-instead-of-hanging","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Stalled WebSocket sends are now detected instead of hanging\n\nA WebSocket whose outgoing buffer never drains is now detected after 60 seconds instead of hanging.\n\n**What**\n\nThe 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.\n\n**Details**\n\n- 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.\n- `sendPauseAfterPendingBytes` defaults to 0.\n- No gate; this applies to all WebSocket traffic.\n\n**Evidence**\n\n`sendStallTimeoutMs`\n\n- Area: Session Transport\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}