zarazaex69 95fd5b7d3c fix(server): tolerate stale control frames during handshake ...

After a session reinstall, the old client's control loop may have
already written a CONTROL_PING frame to the link before its context
was cancelled. This frame arrives at the server's new smux session and
is routed to the handshake stream (matching stream ID), where the
framing layer interprets the JSON bytes as an impossibly large length
prefix ('{\x22ve' = 2065856101 > 65536).

Previously this triggered a full reinstall, which could cascade into
a reconnect storm. Now acceptHandshake and acceptPeerHandshake
recognize ErrFrameTooLarge as a stale-frame artifact: they close the
polluted stream and retry AcceptStream up to 3 times, giving the real
CLIENT_HELLO a chance to arrive on the next stream.

2026-06-13 02:53:22 +03:00

..

builtin

fix(jitsi): require targeted peer frames for clients

2026-06-05 18:11:46 +03:00

goolom

test(e2e): tune videochannel params and reduce chunk timeout

2026-05-28 13:19:14 +03:00

jitsi

fix(server): tolerate stale control frames during handshake

2026-06-13 02:53:22 +03:00

livekit

fix(client): survive liveness loss without killing SOCKS listener

2026-05-21 13:42:22 +03:00

engine.go

fix(jitsi): require targeted peer frames for clients

2026-06-05 18:11:46 +03:00