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.)

[surdotranslater-lgtm]

UPDATE (Jul 17) — root cause narrowed with client traces and controlled experiments. Please read: this contains the exact SFU error, the node name, and a likely missing SDK fix.

1. The exact failure, captured from SDK diagnostics (control call, Jul 17 07:31:36–07:32:46 UTC).
The Android publisher joins, publishes both tracks, completes ICE — and ~2s later the SFU itself declares the transport dead and force-rejoins the client:
sfu_error: {“payload”:{“error”:“publisher PC negotiation failed”,“strategy”:“rejoin”,
“code”:“participantMediaTransportFailure”},
“peer”:“0-sfu-oci-stockholm-vp1-208d834d2c70.stream-io-video.com”,
“timestamp_ms”:1784273498235}
Error: {“error”:{“message”:“publisher PC negotiation failed”,
“code”:“participantMediaTransportFailure”,“shouldRetry”:false,“reconnectStrategy”:3}}
callReconnect: {“strategy”:“rejoin”,“reason”:“sfu error: publisher PC negotiation failed”}
sfu_socket_disconnected: {“closeCode”:1006,“closeReason”:””}

Because shouldRetry:false forces a FULL rejoin each time, the client loops: 3 failed attempts
(user sessions 8cde5bfa-c5a6-4849-a7d4-7b7d598a2239 2s, a7897ac5-bd3d-4c66-ac9a-ebfe2a1258c7 1s,
e8469f0c-fef0-4080-ac33-d0c5300ab4db 3s), 4th sticks (8fb1a566-3d4c-48b2-8805-784a15c2e3fe, 17s).
All four attempts on the SAME node. These session IDs are ready for your SFU-side log lookup.

2. We eliminated everything on our side, one variable at a time (all verified by test calls):

• closed_caption_mode disabled (06:49:41 UTC) → flap persists;
• frame_recording disabled (06:58:01 UTC) → flap persists;
• broadcasting.hls.auto_on disabled (07:18:05 UTC) → your broadcasting-hls-egress agent left our
  calls, SFU count dropped 2→1 — and the flap STILL persists on a single SFU with no server-side agents.

3. Perfect A/B on the same node instance (07:51:43 UTC): an iOS↔iOS call through the very same
sfu-oci-stockholm-vp1-208d834d2c70, one iPhone on the same network/IP as the failing Android,
same SDK version (stream-flutter v1.4.1): publisher negotiated instantly, single clean sessions
(f24d6cd0-2e01-41ef-a777-c692e0c09b38, 9e9e9f1d-e36b-448f-bdd9-abde79182b4a). The node and the
network are healthy — the failure is specific to the Android publisher bring-up.

4. Cross-region reproduction (~08:09 UTC): with a temporary non-EU geofence the same Android
client was routed to sfu-oci-mumbai-vp1-e46151e117e0 — identical failure (sessions
94e19bb7-d3e7-4902-875c-1a58cd3b0748, d4eb3d1b-bd55-4be6-b408-c9497e72305f). So this is not one
node or one region: it follows the Android client across your fleet. Same-hour dichotomy holds all
day: every Android↔iOS call flaps (publishers 4-5/2), every iOS↔iOS call is clean (2/2), and in
degraded calls the VIDEO track suffers first (clean calls always have audio==video durations).

5. Why we think we know what happened. This failure class — "failed SetPublisher → republish
silently reuses a cached transceiver → track never announced" — is known to you as REACT-1020
and was FIXED in your JS SDK: PR stream-video-js#2309 ("fix: renegotiate unacknowledged publisher
transceivers on republish", merged Jun 30), shipped in @stream-io/video-client 1.55.1 (Jul 2),
announced in your changelog Jul 6, ported to video-react-native-sdk 1.40.1. The Flutter SDK has
no equivalent fix (nothing in 1.4.1, nothing in the unreleased 1.4.2 on main). If the SFU-side
counterpart of that change rolled out around Jul 16 (~09:00–12:20 UTC), every unpatched Flutter
Android client would fail exactly as documented above — while your JS/React/RN customers, already
fixed client-side, would see nothing. Related unfixed Flutter history: #1124 (same
participantNotFound@setPublisher signature, closed stale), #913, #1067.

Our asks, updated:

1. Port #2309 (REACT-1020) to stream-video-flutter, or advise a client-side mitigation we can
   ship — this is a production accessibility service (deaf users ↔ sign-language interpreters) and
   it has been degraded since Jul 16.
2. Confirm whether an SFU-side rollout touching publisher negotiation/transceiver handling went out
   on Jul 16 between ~09:00 and 12:20 UTC.
3. Pull SFU logs for the session IDs above — what exactly fails in the Android publisher DTLS/ICE
   bring-up that returns participantMediaTransportFailure with shouldRetry:false?
4. Separately: ring-push delivery to device registrations created before ~09:00 UTC Jul 16 silently
   stopped until users re-logged (fresh registrations kept working). Please check push delivery logs
   for app 1329635 in that window — was there a push-pipeline (V2→V3) change?

Everything above is reproducible on demand; we can run any additional test call within minutes.

[Brazol]

Hi @surdotranslater-lgtm, thanks for the very detailed report, we're looking into it. No firm conclusion yet, but a couple of early observations:

• Some of the calls (e.g. default:pewu57bdg1) look like a client-side issue: there's a failed getUserMedia with a NotAllowed reason, which points to declined camera permissions.
• Other calls are a different: getUserMedia succeeds, the publisher connection reaches the SFU, but the media transport fails to establish and the client keeps rejoining. I've raised this with the backend team.

On the JS renegotiation fix - we'll likely implement the equivalent in Flutter as a safeguard, but I'm not sure it'll help here. On rejoin we already recreate the RtcManager and all transceivers from scratch, so it shouldn't change the consecutive failures your user hit.

I'll follow up once we hear back from backend.

[Brazol]

Hi @surdotranslater-lgtm, we found and fixed the issue that was causing the problems you reported. The fix has been implemented on the backend, as well as on the SDK side starting with v1.4.3.

You should hopefully already see an improvement thanks to the backend fix. Please update to the latest SDK version as well, and let us know if you’re still experiencing the issue or run into any other problems.

I’ll close this issue for now. Thanks for reporting it!