Breakout Troubles and Crashes

Using the latest Zoom SDK on Windows (saw the issue in previous versions as well).

I am working on adding control of breakouts to my app. I want to create, delete, open, list, and close breakouts, and then I want to send people to breakout rooms, move them between rooms, recall them from rooms to the main space, and then eventually assign and unassign users before the rooms are open.

Here are the results I get when trying to implement this:

-List breakouts works as expected
-Close breakouts works as expected
-Send to and move between works as expected

-Recall from breakout to main area: I am unclear how this is done in the v2 interface for breakouts. What do I need to call?

-Open breakouts does not succeed. My call is
SDKInterfaceWrap::GetInst().GetMeetingService()->GetMeetingBOController()->GetBOAdminHelper()->StartBO()
and I do this after creating the rooms. It returns false. Clicking the close button in the Zoom UI succeeds.

Delete breakouts has a bug, but does succeed
When using this function in the UI, if you create a breakout in the SDK or UI, then delete it in the UI (have not tried making this crash happen in just pure SDK calls), then open breakouts, then send any user to any breakout, the SDK app will crash without catching anything in the IDE. It seems like a very low level issue. I can email in a crash log if needed.

Assign to breakouts / unassign from breakouts returns success but does not apply
My call to assign is
SDKInterfaceWrap::GetInst().GetMeetingService()->GetMeetingBOController()->GetBOCreatorHelper()->AssignUserToBO(w_bo_uid, room_id.c_str())
My call to unassign is:
SDKInterfaceWrap::GetInst().GetMeetingService()->GetMeetingBOController()->GetBOCreatorHelper()->RemoveUserFromBO(w_bo_uid, room_id.c_str())
These return true but do not actually apply the action.

I know you have done some breakout tests recently, can we compare notes on the above and figure out where I am either finding bugs or doing something wrong? Thanks in advance.

Hey @liminal_andy,

Thanks for using the dev forum!

Thank you for the compiled list here. I want to test all of these as well, but under the same conditions as you. I will be OOO tomorrow and will be signing off soon. So I will have to circle back up with you here on Monday. In the meantime, can you zip your modified C#Wrapper and send it to me at DeveloperSupport@zoom.us so that I can compare it with my wrapper when I am testing?

Thanks!
Michael

Hey Michael, I actually use the C++ SDK versus the wrapper. Is there something else I should send?

Hey @liminal_andy,

Oh sorry, no my bad my eyes saw InterfaceWrap: and read Dot_Net_Wrap haha.

Michael

1 Like

Hey @liminal_andy,

When an attendee calls LeaveBo() from the AttedeeHelper, they will return to the main meeting room.

This looks to be a race condition. I didn’t see this in prior testing as I had a custom button to call StartBO(). However, when I created a room, assigned user(s) to it, then tried to call StartBO() all in one action, I saw the same behavior as you.

Yes, if you could please send your code SDK logs, and crash dump that would be awesome.

How exactly are you verifying that these are not applying? Through the UI, through callbacks?

Thanks!
Michael

Hey Michael,

On item 1, what if I do not have an SDK client for the attendee? Is there no equivalent call to the “remove from breakout” option in the UI as a breakout administrator? I won’t have the option of deploying my app on the attendee end.

On item 2, I also stagger my actions but do not achieve success in opening the rooms. Is my call correct?

On item 3, I will email a log and dump to the support email shortly

On item 4, I am verifying by opening the UI after creating the assignment and observing that the assignments have not applied.

Hey @liminal_andy,

I see. Hmm, yeah I am not sure this is currently possible without a workaround. I suppose you could re-assign the user to a new BO room then delete that room, but that is definitely tedious for this purpose. Let me circle back with you on that one.

After you stagger the actions is CanStartBO returning true? How are you staggering the calls?

Thanks!

So after assigning the users, what happens after you start the breakout rooms? Are they still un-assigned? (I know you havent been able to start the rooms yet, but that is the next thing to investigate).

I am thinking that in your application the user assignments are racing with the starting of the breakout rooms still. Can you verify all the users have been assigned to rooms, wait a little bit, then try starting again?

Thanks!
Michael

Great, ran some more tests:

  1. As fun as an escape pod breakout room would be, I think the constraints of that system for the end user would indeed be too tight. A command equivalent to the SDK’s UI element for removing someone from a breakout seems the most logical way forward.

  2. Doubled the delay in my test suite, now we’re in business!

  3. Need to build another dump, sorry for the delay

  4. Doubling the delay has caused better behavior, I need to do a rigorous test to be sure

One other small note, regardless of what delay I use and if the action actually takes place, the callback is SUCCESS, so that’s worth looking at if nothing else.

Hey @liminal_andy,

By callback, do you mean the return value of the method? Or are you referring to a particular event callback?

One confusing thing about the SDK in general is lots of methods return an SDKError enum, that is actually representative of if the call was able to made. Then, there is usually a corresponding event callback that reports on the actual result of the call.
For example, you can call joinMeeting() and if it returns Success, it does not mean the user successfully joined the meeting. Rather it meant that the SDK was able to call joinMeeting(). You would have to list to the relative callback onMeetingStatusChange to see the result of calling joinMeeting().

Thanks,
Michael

Hi Michael, I will loop back ASAP on this, need a bit more testing time.

1 Like

Hey @liminal_andy,

Sounds good, keep me posted!

Michael