{"version":"2.1.248","anchor":"streaming-frames-are-dropped-rather-than-replayed-late-after","canonical_anchor":"streaming-frames-are-dropped-rather-than-replayed-late-after","heading":"Streaming frames are dropped rather than replayed late after a reconnect","tier":"notice","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/streaming-frames-are-dropped-rather-than-replayed-late-after","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Streaming frames are dropped rather than replayed late after a reconnect\n\nStreaming text produced while the connection is recovering is dropped instead of arriving in a late burst.\n\n**What**\n\nWhen the remote bridge is holding traffic because writes are gated or the transport is recovering, `stream_event` frames are filtered out and counted instead of buffered. Streaming deltas produced during the gap are lost rather than arriving in a burst after the connection returns; only the other frames are queued and replayed.\n\n**Evidence**\n\n`stream_event frame(s) during flush`\n\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}