From d9198727d979d41f342d78bd02e008a374ebb059 Mon Sep 17 00:00:00 2001 From: Russell Ballestrini Date: Wed, 3 Jun 2026 20:06:36 -0400 Subject: [PATCH] =?UTF-8?q?zebra-spaces:=20stream-toggle=20reliability=20?= =?UTF-8?q?=E2=80=94=20await=20sinkId,=20drop=20stalled=20handler,=20idemp?= =?UTF-8?q?otent?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fox saw repeated "stream stalled" and "autoplay blocked: aborted at user's request" log lines on both auto-enrolled mobile listeners and host self-monitor clicks. Three coupled causes: 1. applySinkTo() was called sync-fire-and-forget right before setting .src and calling .play(). setSinkId() can re-init the media pipeline; when it landed during the in-flight load it aborted the request — Firefox surfaces that as "The fetching process for the media resource was aborted by the user agent at the user's request." on the play() promise. We wrongly logged that as autoplay-blocked. Fix: await applySinkTo() BEFORE assigning .src. 2. The 'stalled' event handler called unmuteWebRtcOnFail every time it fired. 'stalled' fires constantly during normal mobile-cellular buffering and isn't a terminal failure. Each fire ping-ponged the audio path between WebRTC (unmuted) and the still-loading HTTP stream. Drop the handler — only 'error' and a rejected play() promise indicate real failure. 3. A second toggle-on for the same pubHex (auto-enroll race when peer-joined fires during initial enrol) reassigned .src on the same