{"version":"2.1.275","anchor":"remote-control-repl-bridge-now-relays-queued-notifications","canonical_anchor":"remote-control-repl-bridge-now-relays-queued-notifications","heading":"Queued notifications now require a remote connection to deliver","tier":"notice","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275\/e\/remote-control-repl-bridge-now-relays-queued-notifications","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.275","markdown":"### Queued notifications now require a remote connection to deliver\n\nQueued notification messages are relayed through Remote Control but get dropped with a warning if there's no remote transport to route them to\n\n**What**\n\n- The Remote Control REPL bridge now relays queued notifications into the app during a bridge session, using the same handler as before.\n\n- An incoming `queued_notification` control message is now dropped (and not acknowledged) unless the session is using a remote transport, logging a warning and recording a new telemetry reason.\n\n- The warning text shown when a queued notification has nowhere to go was reworded from referencing \"remote mode\" to referencing a missing \"ingress host\".\n\n**Why**\n\nThis ensures queued notifications are only delivered when there's an actual remote connection able to receive them, and makes the failure message clearer about why a notification was dropped.\n\n- Area: Remote Control\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}