stream_video 1.5.0 (also stream_video_flutter / stream_video_push_notification 1.5.0), Flutter 3.47.2, iOS 26.6.
Answering a ringing call on the CallKit screen of a locked iPhone, while the app is still cold-starting from the VoIP push, kills the call.
verifyIncomingCall sees the call is no longer ringing, and calls endCallByCid(cid, silent: true) → endAllCalls(), which ends the CallKit call the user just answered. iOS then releases the app's process assertion, suspends the app, and the in-flight call.join() never returns.
Callee device log — 10 ms between our join starting and iOS tearing it down:
11:37:09.379 flutter: [calls] joining voice:b12a2c44… (outgoing: false, Incoming{acceptedByMe: true})
11:37:09.389 callservicesd: Invalidating process assertion for <app>
11:37:09.442 callservicesd: releasing PowerAssertion
11:37:09.539 callservicesd: Stopping audio session
join() never returned. It is a suspension, not a hang — an identical stall resumed and printed joined 3 minutes later, the moment the phone was unlocked. The caller joined normally, saw no remote participant, and gave up after 42 s.
The _isAnsweredOnThisDevice guard should prevent this, but on the cold-start path neither branch is true yet: activeCalls doesn't contain the call (join still in flight), and the native entry was already consumed by consumeAndAcceptActiveCall().
This is the code from #1298 (merged 2026-08-12, shipped in 1.5.0), which added the dismissal, the silent flag and that guard. No open issue covers it.
Repro: force-quit the callee app, lock the phone, call, answer on the CallKit screen within ~3 s. Answering with the screen on works.
Happy to supply full logs from both handsets.
stream_video 1.5.0 (also stream_video_flutter / stream_video_push_notification 1.5.0), Flutter 3.47.2, iOS 26.6.
Answering a ringing call on the CallKit screen of a locked iPhone, while the app is still cold-starting from the VoIP push, kills the call.
verifyIncomingCallsees the call is no longer ringing, and callsendCallByCid(cid, silent: true)→endAllCalls(), which ends the CallKit call the user just answered. iOS then releases the app's process assertion, suspends the app, and the in-flightcall.join()never returns.Callee device log — 10 ms between our join starting and iOS tearing it down:
join()never returned. It is a suspension, not a hang — an identical stall resumed and printedjoined3 minutes later, the moment the phone was unlocked. The caller joined normally, saw no remote participant, and gave up after 42 s.The
_isAnsweredOnThisDeviceguard should prevent this, but on the cold-start path neither branch is true yet:activeCallsdoesn't contain the call (join still in flight), and the native entry was already consumed byconsumeAndAcceptActiveCall().This is the code from #1298 (merged 2026-08-12, shipped in 1.5.0), which added the dismissal, the
silentflag and that guard. No open issue covers it.Repro: force-quit the callee app, lock the phone, call, answer on the CallKit screen within ~3 s. Answering with the screen on works.
Happy to supply full logs from both handsets.