Waiting room: admit (putonhold) sometimes fails

@alexander.brotzge

I’m curious about how you manage the user.id information between connection / disconnection of your users ?
You problem seems to be related to what i already reported here :

I did not check the details, but it looks like you keep track of userId on a list (waitingRoomParticipants) and invoke the function to put them back & so on. But because of the user id renewal stuf, it would work the first time only since your users are going to reconnect when putting back on the meeting from the waiting room and thus change their user id information. It might be the cause of the error code you get, because it’s kinda weird to receive such a message about rate limit when you are clearly not requesting much the API… if that’s the real cause, then Zoom should also fix that incorrect error code handling. (If not please just ignore)

If that’s not the real issue, it might also comes from the fact that you permanently add new user data to your list since the id of a user is renewed when reconnecting to your meeting from the waiting room.
Since you’re doing a loop from that list that potentially grow indefinitely (you do not seem to purge it), you may reach the API rate limit during one of your loop processing.

@MaxM So it looks like this whole user identity thing i reported a while ago is still not fixed. Could you please re-open my thread (see above) with a status update ? You’ve published a feature that is “half coded” and un-usable, that’s a pity. I think we all want to use it so, when is it going to work ?