I got meeting.participant_left and meeting.participant_join event upon host admit new user joined the session.
Not an error but i’m wondering is that the expected behavior ?
Which App Type (OAuth / Chatbot / JWT / Webhook)?
It’s a webhook.
It’s a webhook.
How To Reproduce (If applicable)
Steps to reproduce the behavior:
- Join a session using join url
- Host admit newly joined user
- Get the webhook events
Screenshots (If applicable)
If applicable, add screenshots to help explain your problem.
Add any other context about the problem here.
I was able to reproduce this behavior. Seems like a bug on our end when waiting room is enabled for the meeting. I will report it to the associated team and confirm if it is bug or not. Thank you for your patience and for letting us know!
Thank you for your response. Can you reply on this topic if there are some updates ?
Absolutely! This is an error in the current design [Join in the waiting room (participant joined) -> Left the waiting room (participant left) -> Join the meeting (participant joined) -> Left the meeting(participant left) ] and I have submitted a Jira( Jira #ZOOM-152903 ) for internal tracking reference) to the engineering team to fix it.
Thanks again for reporting this!
Any updates for this behaviour ?
I do not have an update yet as this is currently in the backlog. It will be updated in the Changelog when the fix is released and I will ensure to inform you here as well!
Hi, thanks for the update.
If it’s possible, can you please elevate this issue. To be honest, one of our project is on production and really affected to this behavior change especially disconnection feature.
Currently the functionality is:
Join in the waiting room (participant joined webhook sent) -> Left the waiting room (participant left webhook sent) -> Join the meeting (participant joined webhook sent) -> Left the meeting(participant left webhook sent)
We are currently working on improving this, but as a work around you could implement logic on your end to account for how it works.
In your proposed workaround, do you expect us to keep state and track join (waitroom) -> left (waitroom) -> join (meeting) -> left (meeting)?
How else are we supposed to differentiate waitroom or meeting joined/left events? Do the event body properties differ?
Hi @tommy , Thanks for the update.
As @recordedspeed said, are there any ways to differentiate the waiting room and meeting events ?
Hi @recordedspeed & @carrpirates, we are working on providing this differentiation directly in events, but do not have a precise timeline.
No timeline as of yet, but it is in our backlog.
HI @tommy and @michael.harrington , thanks for all your replies on this thread!
I understand that the actual fix is in your backlog and that is fine, but I want to understand if there is a way for us to differentiate from “waiting room join” vs “normal join” so that we can filter them out.
Currently I see that both events are identical, except for the userId that changes, but I guess there is nothing we can do on our side to differentiate them, right?
Thanks in advance!
Unfortunately there is no easy way to find the difference. We are working to release this in the next few months.