Fox 2026-06-05 telemetry on host: "host is hearing two" — peer-joined
u=64b0 (fxhp-phone rejoin with new uuid, same pubkey) fired THREE
attach calls within 1 second for the SAME uuid:
Call 1: pool=1 → fallback <audio> path, "tracks=0"
Call 2: pool=1 → AudioContext success
Call 3: pool=2 → AudioContext success (after mesh stream swap)
Three overlapping audio chains = "two streams" perceived.
Root causes:
1. flushSfuStreams used the cached sfuStreamsByPubHex entry, which still
pointed at the OLD phone session's stream (uuid=91ab had left 5s
earlier). Old stream's audio tracks were ended. attach received a
zero-live-track stream and fell through to <audio> fallback.
2. Multiple paths (peer-joined → flushSfuStreams, sub PC ontrack,
mid-spotlight supplant) each tried to attach the same uuid in the
same tick. No idempotency check, so each call tore down and rebuilt.
Two fixes:
A. attachAudioStreamViaWorklet: reject streams with zero live audio
tracks (skip silently); make same-uuid + same-stream calls a no-op.
Repeated calls during a peer-joined burst stop racing.
B. handleRemoteSfuTrack: listen for the cached track's 'ended' event
and drop the sfuStreamsByPubHex entry. Next flushSfuStreams won't
hand a dead stream to attach.
Combined: the publisher's rejoin cycle now produces exactly ONE attach
chain — the one fed by the live ontrack — and ignores stale cache hits
+ duplicate attach calls.
Russell Ballestrini
f479878fff