We are currently experiencing an increase in Errors (code: 80003) with the getBreakoutRoomList() method.
Error: No Permission for this API. [code: 80003, reason: require_meeting_owner_role]
It doesn’t seem to occur for us consistently; we call the API and sometimes it works, but other times it fails with this error.
This seems very unusual, and we haven’t experienced it before. The Meeting Owner role is definitely mine (I tested it numerous times in my own Personal Meeting) and the Meeting Owner obviously does not change (it can’t)
Sorry to sound the alarm… after some further investigation it looks like this only occurs on getBreakoutRoomList() when the host is moving rooms (during or soon after calling changeBreakoutRoom)
Not as high impact as we initially thought. The output looks to be correct some time after the host has moved
Thanks for keeping us posted on this. It sounds like for now the workaround is to add a delay before making the API call. I’ll keep you posted on any info from our engineering team.
Similar drift to these - it seems that sometimes our customers experience the same exception on different calls - either the onActiveSpeakerChange event or the getMeetingContext call.
Would the same workaround of delaying the call work?
@nikhil2 those two events are in fact only available to the meeting owner. What is the exact exception you’re seeing? Is it require_meeting_owner? If so, this is expected
Jon - the meeting owner is the user that’s invoking those methods. I independently check that the current user is the meeting owner on our backend by making sure that the current user’s zoom user id and the meeting’s host_id are equal. When they aren’t equal, I block going to the page where those method invocations happen if the current user is not the meeting owner.
I’m also led to believe that this is a bug because it happens non-deterministically; it’s only affected some of our customers some of the time, and I’m unable to reproduce it myself. Upon looking back on our backend logs and talking to our customers who it affected, I couldn’t find any difference between calls where the invoking those methods succeeded and failed.
Thanks Nikhil. Are you able to tell us anything about the impacted users that is different?
-Were they recently made host, eg by someone else or from host leaving the meeting?
-When was the last time the url changed?
-When was the last time the config method was called?
To debug, and/or as potential workaround, I would consider re-running config before the getMeetingContext invocation or following a event onCohostChange and see what happens.
Meanwhile I’m going to raise this internally and see if anyone knows what’s happening
Nikhil, I believe it’s a situation where we report error message incorrectly. Most likely, what is happening is race condition of some kind: either rooms are being reconfigured when the method is called, or host is in transition between rooms.
Can you please check this?
Options to resolve would be accurate event tracking to prevent method from being called in transition, or retry the call attempt with a delay in case of an error
