starting a VC with 2 people + a invitee can result in very strange race conditions
Starting a voice/video conference (VC) with 2 people + a invitee can result in very strange race conditions.
Reproduction instructions
- have a room with 2 people (A,B) + invitee (C)
- user A hits video call button - starts 1:1 with B
- C joins the room
- user C starts a voice/video conference
- all hell breaks loose, with Voip Conference users appearing in the memberlist and all sorts.
The simple solution here would probably be to just start a conference if we have invitees
The correct approach would be to check if the room is not a DM and if it is not, then start a conference call instead of a 1:1 call
The correct approach would be to check if the room is not a DM and if it is not, then start a conference call instead of a 1:1 call
I would argue that we should just check the member + invite count. Making this dependent on whether the room is a DM or not seems a little unideal. Both because people have DMs with more than 2 members and because this can break at times
The correct approach would be to check if the room is not a DM and if it is not, then start a conference call instead of a 1:1 call
I would argue that we should just check the member + invite count. Making this dependent on whether the room is a DM or not seems a little unideal. Both because people have DMs with more than 2 members and because this can break at times
That would work unless a call is already in progress. Good point about DMs having more than two members. Can we do a check on "if room is not a DM or a DM and has 3+ members"? I defer to @dbkr to check the logic.
That would work unless a call is already in progress
If a call is already in progress, I don't think this can work?
I think the best could actually be "If a room is not a DM or has 3 >= members/invitees"
Yeah, we could do that check. I guess it depends on what expectations are of DM rooms, Generally the intention would be to talk to a specific person, so a 1:1 call would make sense: especially if the other user was a bot, but there are probably other cases.
Also worth noting that this bug sounds like it was originally about the old, old MCU based conferencing (since it talks about voip conference users) although obviously the behaviour is still a little odd.
Removed good first issue and Help Wanted as solving this causes other bugs
Will be fixed by Element Call