Android publishers need 3-4 publish attempts (or never publish) since 2026-07-16 on our app, while Stream demo app is clean on the same device — SFU-side per-app issue?

[surdotranslater-lgtm]

Environment

• stream_video / stream_video_flutter / stream_video_push_notification: 1.4.1 (latest)
• Flutter app in production (sign-language video interpretation, Ukraine)
• App api_key: cj3r5ae7ekvw, call type: default
• Affected: Android 13 (TP1A.220624.014) and Android 16 (BP2A.250605.031.A3) devices, multiple networks
• NOT affected: iOS (stream-flutter) and web (stream-react) participants, all day

What happened

Since 2026-07-16 between 09:18 and 12:21 UTC, Android participants stopped publishing media
on the first attempt. The UI shows 3 consecutive reconnects and the call finally works on the
4th attempt; in several calls the Android side NEVER published (the interpreter could not see
or hear the deaf user), while remaining subscribed. Once connected, quality is perfect - your
call reports show score 87-99 for the affected sessions, so this is not network quality.

Why we believe this is server-side, scoped to our app

1. Your own demo (getstream.io/video/demos in Chrome AND your demo app) on the SAME affected
   Android device and SAME Wi-Fi: 60+ seconds in call, zero reconnects. Our app keeps flapping
   on that device.
2. Our store binary is unchanged for weeks and was verified clean on 2026-07-03 and on the
   morning of 2026-07-16 (publishers 2/2, scores 94-98). No app release, no backend deploy,
   call-type config untouched since June 30 (updated_at confirms).
3. Mobile-data test on the affected device: ~50% of attempts died in reconnect stages -
   network-independent.

Evidence (2026-07-16, UTC) - publishers total/unique > 1 = repeated publish attempts

• 12:21:19 default:zha1zu9j0n session 8398d1a3-bab0-49cd-a9cf-98e6381aa602 - 3/2, score 99
• 13:32:42 default:rtem5h94ft session 910f67ee-fad7-4e0e-8025-8a9fc630e33d - 5/2, score 61
• 13:47:09 default:pewu57bdg1 session 184cd9c8-126e-4c00-b6fc-4db3a2f94538 - 1/1, android never published, score 98
• 14:03:51 default:78a60ofnhc session 0bac3d3d-6cfb-4b83-800d-2e5f1c946e94 - 5/2, NO video at all, score 87
• 14:19:56 default:zmj1jcql6d session 27a1b139-0446-4be9-93f9-81b7385d47d4 - 5/2, video late, score 98
• 16:55/16:58 default:62juz6xkx7, default:cn0y6noth2 - both 5/2, score 98 (latest reproductions)

Counter-example mid-incident: 13:53:05 default:ngpuxn4dey session
033fcf98-c9cd-419f-b9f8-f3dec21a8944 - android published cleanly (2/2, score 93).

Baseline (same devices/build): 2026-07-03 default:5vf95gkru5 (2/2), default:kq0m06q3af (2/2);
2026-07-16 morning 06:45 / 09:17 UTC (2/2).

Also, device push registrations created before ~09:00 UTC that day stopped receiving ring
pushes until users logged out and back in; fresh registrations work. May share the root cause.

Ask

1. Which SFU/edge cohort is our app assigned to, and was there a rollout for it on
   2026-07-16 ~09:00-12:20 UTC?
2. Could someone check SFU-side publisher/ICE logs for the sessions above - what failed on
   the first attempts?
3. Any mitigation (pin to healthy cohort / rollback)?

Note: our dashboard plan has no support access, hence filing here. This is an
accessibility-critical production service (deaf users <-> interpreters).
Contact: surdo.translater@gmail.com

[surdotranslater-lgtm]

We also see our dashboard actively promoting the Push V2 → V3 migration — if a push-pipeline
rollout happened on 2026-07-16, it would explain why pre-existing device registrations went
silent while fresh ones kept working. Was there such a rollout? (We have NOT clicked "Upgrade
to V3" — still on V2, both providers enabled and unchanged.)