Auto recording doesn't work from time to time

Hi there!

Could you help me to understand why some of our meetings weren’t recorded please?

Let me explain our flow. So we have 250 paid licenses in our ISV account. We rotate them between the users:

  1. Our Platform creates meeting via Zoom API

  2. Before the user joins the meeting room, our system sends PATCH request to users/${userId} and updates user license (type: 2)

  3. After that our system sends request to meetings/${meetingId} and updates auto recording setting to cloud

  4. When meeting ended we change license type of the host user to basic

It works just fine in the most cases. However, I found that some meetings weren’t recorded, but our system sent correct requests to update license and enable auto recording.

Could you help me to investigate what was wrong please? I just want to understand why these meetings weren’t recorded. Either license wasn’t assigned to host user or meeting’s auto recording setting wasn’t updated.

Example of meeting ID: 97543662156 for user

You can also check our logs:
// Updating user license

{“application”:“topcall”,“axiosData”:{“type”:2},“axiosMethod”:“patch”,“axiosUrl”:“/v2/users/”,“level”:“info”,“message”:“Start external request”,“responseTime”:13,“timestamp”:“2023-08-08T19:15:17.759Z”}
{“application”:“topcall”,“axiosMethod”:“patch”,“axiosRequestData”:{“type”:2},“axiosResponseCode”:204,“axiosResponseData”:“”,“axiosUrl”:“users/”,“level”:“info”,“message”:“Finish external request”,“responseTime”:345,“timestamp”:“2023-08-08T19:15:18.091Z”}

// Updating meeting auto-recording setting

{“application”:“topcall”,“axiosData”:{“settings”:{“auto_recording”:“cloud”}},“axiosMethod”:“patch”,“axiosUrl”:“/v2/meetings/97543662156”,“level”:“info”,“message”:“Start external request”,“responseTime”:346,“timestamp”:“2023-08-08T19:15:18.092Z”}
{“application”:“topcall”,“axiosMethod”:“patch”,“axiosRequestData”:{“settings”:{“auto_recording”:“cloud”}},“axiosResponseCode”:204,“axiosResponseData”:“”,“axiosUrl”:“meetings/97543662156”,“level”:“info”,“message”:“Finish external request”,“requestId”:“c2483b44-72f1-441d-a205-018d43398ccb”,“responseTime”:582,“timestamp”:“2023-08-08T19:15:18.328Z”}

As you can see, both requests finished with 2xx status codes without any issues, so I assumed that if user opens start url with ZAK then he will be joining as host and recording will be started. And it works exactly like that in the most cases, however sometimes meetings are not recorded.

Could there be any race condition on your side between user license update and meeting setting update?

Best regards,
Alexey Frank

Hi @alexeyfranktt
Thanks for reaching out to us, I am happy to help here!
Allow me some time to look into this issue and I will come back to you with updates or to request you some more details.

Hi Elisa!

Thank you for response, just wanted to ask if you have any updates?

Best regards,
Alexey Frank

Hi @alexeyfranktt
Unfortunately, I was not able to replicate this issue on my end, but while I was trying to do so, I kept thinking about this, is there a reason why you do not create the meeting with the auto_recording set to cloud since the begging? Why is it that you have to update it ?

Hi Elisa!

yes, as I said we have limited amount of licenses, and we have to rotate them among our users. That’s why we assign the license and change auto recording setting right before the first participant joins the meeting room.

We still face the same problem, maybe it’s possible to check logs on your side? I’m just wondering if there be any kind of race condition, and at the time we update auto_recording setting, the meeting’s host is still considered as unlicensed user

Hey @alexeyfranktt
sorry for the late reply here! I did not get a notification with this last message.
This could be an issue of timing as you mentioned, by the time the auto_recording setting gets updated, probably on our end the user has not been updated.
I am happy to look into this.
I will go ahead and send you a private message so you can share some logs with me