Telemetry showed Willdabeast's mesh PC (peer edc257b4...) failing every
~20s in a perfect loop for 4+ minutes — the old 1.5s flat retry was
firing connectToPeer over and over against a NAT we couldn't traverse.
Each cycle ate CPU, network, signaling churn, and contributed to the
robot-voice + lost-mic noise we've been chasing.
New behavior:
- 2s -> 4s -> 8s -> 16s backoff (capped) between attempts
- Hard cap at PEER_MESH_MAX_RETRIES = 4 attempts. After that,
peerMeshGiveUp.add(uuid): connectToPeer becomes a no-op for that
uuid and audio rides on SFU permanently.
- Successful 'connected' transition resets the retry counter so a
much-later transient blip gets a fresh budget.
- peer-left / peer-booted clear all retry state via
clearMeshRetryState() so a rejoin from the same uuid starts over.
Log lines surface the decision so the next pathological mesh peer
shows up in CLIENT_LOG as 'mesh failed Nx — giving up, audio stays
on SFU' rather than a wall of identical 'failed — reconnecting' lines.
Side benefit: less mesh churn means the SFU mic fallback path (the
2f1e481 + 441c086 fix) gets to settle and stay settled, so receivers
don't keep flipping their audio elements between mesh and SFU
streams under a failing peer.
Russell Ballestrini
867333f6a5