1145864 - error: there are two people in the room already - when there are not

Status: RESOLVED DUPLICATE of bug 1154251

(Hello (Loop) :: Client, defect, P1)

Description

[:shell escalante]

Today 3 Hello users mentioned seeing this error ([e-mail] & Barry, Dan Horner -Tef & ?, Brad & me @ ~7:40 AM EST). Brad and I saw it where I got a "something went wrong" error before he even joined - when we tried to get back into the room, we both saw "2 people already in the room" error (even though no one was).  Trying another room worked fine - so it was that Room that was hung.  

I had AEC and debug logging turned on - but no idea where the logs went (couldn't find a place to copy - so afraid i'm on an e10s Nightly build and logging's not working Bug 1100502). 

I've seen the same error if I join a room, leave, and rejoin.  Hello will let me rejoin that room - but the person i invited gets the "2 people already in a room" (connections not clearing on server?).

Comment 1

[Adam Roach [:abr]]

Until we land the behavior that forces the room owner back into the desktop client if they click on their own link, I would take all of these reports with a grain of salt. I've worked extensively with about half a dozen people who have reported this issue to me personally. Every last one was clicking on their own link and triggering the standalone client rather than using the desktop client to join the room they created. Typically, this required a *lot* of "okay, tell me exactly what you did and exactly what you saw," and took a lot more time than I would have imagined.

I'm not claiming that there's not potentially another bug here, but I don't think we can judge the prevalence of this issue until we take steps to mitigate the "the room creator entered their own room using the standalone client" problem.

Comment 2

[Benoit Girard (:BenWa)]

I seem to hit this bug whenever I try Firefox Hello. I'm not the only one around the Toronto office either.

(In reply to Adam Roach [:abr] from comment #1)
> Typically, this required a
> *lot* of "okay, tell me exactly what you did and exactly what you saw," and
> took a lot more time than I would have imagined.
> 

Saying the STR is complex doesn't mean the bug isn't worth fixing. People will often have to try entering the room several times before they get their headsets working properly and whatnot. This gives complex STR but can be a quite natural usage flow of a RTC tool dealing with user and peripheral issue.

I would even go further and suggest that we should consider blocking on fixing this!

Comment 3

[Mike de Boer [:mikedeboer]]

I agree that we should focus real hard on reproducing this ourselves and working on a fix for this problem. But what would you block on? Further iterations of Hello work? Stop the presses and focus the team on this bug?
I think you mean we should make this a P1 bug, which I most certainly agree with!

Comment 4

[David Teller [:Yoric] - still alive but not very active]

For what it's worth, I got hit with this problem almost every time I used Hello.

Comment 5

[Mark Banner (:standard8)]

Assuming folks aren't attempting to open their own links by visiting the link, but by going through the Hello panel or visiting someone else's link - please can you send me the links to rooms where this has happened (direct is fine if they can't be public). 

We have some server side logging that should at least let us characterise what is happening.

The other question I have is if people are rejoining multiple times at the start of the call, please can you explain exactly why & with which browser versions. This will help us understand the scenarios better & so we can try improving them.

Comment 6

[David Teller [:Yoric] - still alive but not very active]

From the top of my head, the STR were along the lines of:
1. Start a chat;
2. Send the URL to someone else;
3. Something goes wrong for an outside reason (e.g. problem with the wifi, problem with the microphone), causing one of the parties to disconnect either accidentally or as a way to troubleshoot the issue;
4. Attempt to reconnect.

It is quite possible that, as part of step 3, I attempted to reconnect with my own link.

Comment 7

[Benoit Girard (:BenWa)]

What occurred in Toronto when we tried it was effectively the same from webRTC's point of view but caused by a non technical issue:
1. Start the chat.
2. Second user joins.
3. One of the user leaves the chat.
4. Second person asks the user to rejoin to discuss something again.
5. The second user is presented with an error message and is unable to rejoin.

Comment 8

[Vladan Djeric (:vladan)]

I aslso run into this problem often when I try to re-join a room I created with a link that I shared.
Sorry for the me too comment :)

Comment 9

[Vladan Djeric (:vladan)]

btw, I can reproduce that ^ problem 100%

Comment 10

[Romain Testard [:RT]]

(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #8)
> I aslso run into this problem often when I try to re-join a room I created
> with a link that I shared.
> Sorry for the me too comment :)

There seems to be 2 scenarios causing this:
1 You attempt to join someone else's room that appears to be full: the link generator is already joined to the room but instead of using the desktop client UI he clicked his own link. This means that the 1 seat available for link clickers is busy (we always reserve 1 seat for the link generator) and no other link clicker can join.
2 You attempt to join your own room that appears to be full: you clicked your own link when another link clicker is already in the room (only one link clicker can be in a room at a time)

Reporting seems to show that 9% of link clickers granting media on the clicker page end-up in this situation (and then retry joining several times an get again the "room full" message).

So we're working on it on bug 1154251 to prevent link clickers to attempt to join rooms created (another driver for that is cleaning-up the reporting since a lot of people seem to test the product this way and create a lot of fake sessions that make our reporting hard to interpret).
Bug 1066019 will allow link clickers inside Firefox to use the desktop client UI instead of the clicker UI, therefore preventing link clickers to use the standalone link clicker UI when clicking Hello links inside Firefox.

Comment 11

[Adam Roach [:abr]]

(In reply to Benoit Girard (:BenWa) from comment #2)
> I seem to hit this bug whenever I try Firefox Hello. I'm not the only one
> around the Toronto office either.
> 
> (In reply to Adam Roach [:abr] from comment #1)
> > Typically, this required a
> > *lot* of "okay, tell me exactly what you did and exactly what you saw," and
> > took a lot more time than I would have imagined.
> > 
> 
> Saying the STR is complex doesn't mean the bug isn't worth fixing.


If that's how my response came off, I apologize. I didn't mean that the problem wasn't worth fixing, simply that it was *probably* a known issue, and the fix is already scheduled on the roadmap. Let me try again:

Based on prior experience chasing down problems that are described exactly like you have described this problem, I am about 95% certain that this is a duplicate of Bug 1154251. I could spend about 30 minutes of your time and mine becoming 100% sure, but that's a lot of effort for very little value. What I propose is landing Bug 1154251 and then circling back around to see if it fixes your problem, since there is a very high probability that it will.

Bug 1154251 is P1 for Firefox 41.

Comment 12

[:shell escalante]

i am going to close the one I filed as duplicate of bug 1154251 as all discussions point to that being a root cause.  will reopen if still see.  this was delayed but will be uplifted as far as can go when we get to it early in Fx44.

Will retest once landed and re-open if still seeing.