{"version":"2.1.273","anchor":"bridgeccr-sessions-gain-active-subscriber-stream-flush-tuni","canonical_anchor":"bridgeccr-sessions-gain-active-subscriber-stream-flush-tuni","heading":"Remote Control stream events gain a configurable first-flush delay","tier":"use","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/bridgeccr-sessions-gain-active-subscriber-stream-flush-tuni","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### Remote Control stream events gain a configurable first-flush delay\n\nRemote Control sessions can now delay and tune how the very first streamed event is sent to the backend\n\n**What**\n\nThe client that uploads events for Remote Control (bridge) sessions gained a new `streamEventFirstFlushMs` setting, alongside an existing `setStreamEventFlushIntervalMs` setter:\n\n- When `streamEventFirstFlushMs` is set to a value greater than zero, the very first `stream_event` is buffered as ephemeral instead of being sent immediately, short-circuiting the normal flush-interval batching just for that first event.\n\n- Both the flush interval and this new first-flush delay are now pushed into the client at runtime via the periodic config-apply routine, alongside the existing no-subscriber flush interval, no-subscriber upload hold, and drop-unwatched-events settings.\n\n- The setting defaults to 0 (no delay) and is read from remote config.\n\n**Why**\n\nThis gives finer control over how quickly the first event of a Remote Control session reaches the backend, which can be tuned separately from the steady-state flush interval used for events after a subscriber is actively watching.\n\n- Area: Remote Control\n- Names: `setStreamEventFlushIntervalMs`, `setStreamEventFirstFlushMs`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 2\/5"}