New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users
Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: All
Pri: 3
Type: Bug

Sign in to add a comment
Transition to ICECompleted is flaky
Project Member Reported by, Mar 8 2014 Back to list
In tests, the transition to ICE Connection State == Completed seems to be flaky, especially in tests on Mac OS / iOS, even when all "known" race conditions are fixed.

See also  issue 2993  (test failure) and (deflake by ignoring ICECompleted)
Comment 1 by, May 27 2014
 Issue 3403  has been merged into this issue.
Comment 2 by, May 27 2014
Labels: OS-All Area-PeerConnection Breaks-Bot
@bemasc: in dup  issue 3403  there's a linux repro (in case that's easier for you to use than osx/ios).  Do you think you can get to this soon?
Project Member Comment 3 by, Jun 2 2014
Issue 3432 has been merged into this issue.
Project Member Comment 4 by, Jun 2 2014
Labels: -Pri-2 Pri-1
FTR example bot to observe the flake on is

When the flake hits the test's stderr ends with:
PCTest:offerer still waiting at
    for: [expectedIceConnectionChanges: 1]

Project Member Comment 6 by, Jun 3 2014
Project Member Comment 7 by, Jun 3 2014
The following revision refers to this bug:

r6315 | | 2014-06-03T16:38:08.513442Z

Changed paths:

PeerConnection(java): disable wait for flaky ICEConnection.COMPLETED.

This should be reverted when COMPLETED is delivered reliably.

TESTED=without this patch the test fails in Debug mode after a handful of runs.  With this patch 100 runs passed in a row on my desktop.

Review URL:
Project Member Comment 8 by, Jun 6 2014
Ben, do we understand why this transition is flaky? Please update this bug with the current state.
Comment 9 by, Jun 6 2014
No, there's currently no theory for why this is a problem, but we've seen flakiness on a lot of different tests related to this ICE state now.  Many of them were cured, or almost cured (...) by lengthening timeouts.
I seem to be able to reproduce this issue. I compared logs of successful and unsuccessful connection, in the unsuccessful case I only see "Transport: audio allocation complete" but don't see the same print for the video allocation. I hope this might help to pinpoint the problem
This bug is not related to unsuccessful connections.  It refers specifically to unit test failures in which the connection succeeds, and reaches the "connected" state, but never reports "completed" to indicate that no further changes are expected.
That's my case, but there is no audio or video, so I consider it an unsuccessful call. The call itself seems connected, and I can disconnect and try again. One more input I have, is it only happens when iOS device receive the call (tried from both browser and Android device), but always works when iOS initiate the call.
Project Member Comment 13 by, Oct 16 2014
Labels: Mstone-41 EngTriaged
Guowei,  here's another bug for you :).  It may help you expand you knowledge of the network area.  
Project Member Comment 14 by, Dec 13 2014
can someone still be able to repro this? I have found out couple cases where completed will just not fired. For example, if you have more than 2 networks and both of them have connectivity to the peer. I remedied the problem a bit when the 2 networks belong to 2 different ip family (ipv4 and ipv6).

Could you point me about how to repro this?
Project Member Comment 16 by, Jan 7 2015
Labels: -Mstone-41 Mstone-42
Project Member Comment 17 by, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 18 by, Jan 27 2016
Has this issue been resolved? Saw a similar bug in the M49 release notes.
Project Member Comment 19 by, Jan 27 2016
I'll take ownership from Guo-wei for this one and see if I can reproduce it.

Guo-wei: Is there anything you learned about this issue that isn't mentioned in a comment above? I don't think the "two networks" will be an issue any more, since completed is now defined as "one connection per network" in P2PTransportChannel.
Project Member Comment 20 by, Jan 28 2016
Labels: -Mstone-44
Removing milestone, since fixing this isn't a Q1 OKR.
Project Member Comment 21 by, Nov 8 2016
Labels: Pri-3
Sign in to add a comment