Sorry to hear about your experience. Are you still experiencing the same problem? Just tested on my end and everything seems to be working as expected. Before diving in, can you give me a little more content on the situation? When did this issue begin happening? Has it been occurring constantly, or does it happen on and off? Are you potentially under a corporate VPN or firewall that could be interfering with the connection?
Local machine. No firewall (except Windows). No VPN. Straight to the internet. What makes this very suspect as a potential issue is 2 calls work fine, 3rd fails every time. (See Below)
Here’s the C# routines running. (This is in a loop to loop over existing meetings to check to update them.)
{
var request = (HttpWebRequest)WebRequest.Create(String.Format(“https://api.zoom.us/v2/meetings/{0}”, meetingId));
request.Method = “GET”;
request.Headers.Add(“Authorization”, "Bearer " + accessToken);
try
{
var response = (HttpWebResponse)request.GetResponse();
using (var streamReader = new StreamReader(response.GetResponseStream()))
{
var text = streamReader.ReadToEnd();
return JsonConvert.DeserializeObject<Meeting>(text);
}
}
catch (System.Net.WebException webException)
{
Console.WriteLine(webException);
throw webException;
}
}
3) Issue occurs every time right now.
The failing record is the 3rd call we make in the loop.
First Call: meetings/83856054845 (Works)
Second Call: meetings/83304361404 (Works)
Third Call: meetings/89827698114 (No Response, Times out)
This started happening earlier this week. We’ve been sailing along smoothly for a long while.
Seems like forum lost my post after an edit. So, I’ m reposting reply (in case it shows up twice)
No VPN. No Firewall. Local machine. Straight to internet. This is further evidenced by that 2 calls work, and 3rd always fails. (see below)
Issue occurs every time right now.
We are looping over existing meetings to perform updates as schedule changes occur.
In this scenario, loop always fails on 3rd call.
First Call: meetings/83856054845 (Responds and works)
Second Call: meetings/“83304361404” (Responds and works)
Third Call: meetings/“89827698114” (Never responds, times out)
Started happening this week. Been smooth sailing for a while.
Here’s C# Code we are using (very simple GET call)
OK, I have isolated what appears to be causal, but I do not have an answer for why this is happening.
The routine we are running in question’s job is to scan all of our meetings we need to schedule, loop over them, and either 1) Create a new meeting if it doesn’t exist OR 2) Update the existing meeting’s information with any changes.
Thus, pseudo-code is this:
Loop
{
if (Meeting Scheduled Already)
{
GET: meetingId (retrieve meeting if it already exists.
Update values on meeting object.
PATCH: meetingId (save changes back)
}
else
{
CREATE: (new meeting)
}
}
The problem suddenly began occurring during out latest round. API calls timing out. GETS, but also, the Call to GET the User to create a new meeting against. Thus, we were dead in the water.
Removing the PATCH call fixes all the problems
I just tested removing the PATCH call. Suddenly, all GET calls work. All CREATE calls work. Call to GET USER also works.
I have removed the PATCH call by simply testing if there is any changes and not calling it if there isn’t. Since my dataset is identical, no PATCH calls are made at the momeent, and everything is going smoothly.
The problem is that PATCH call is important. We are running a conference. The schedule is constantly changing, and thus it is necessary to update meeting information over time.
Here’s my questions:
Are there some kind of limitations on the PATCH call?
Is the PATCH call gumming up the API for a Session?
Retrieving a new Bearer Token does not resolve. Still times.
Do you have some kind of arbitrary check on PATCH calls that causes you to start rejecting API calls on a Session if unnecessary PATCH calls are made? (i.e. I’m calling patch but not necessarily updating, your API doesn’t like it, and so blocks all further calls?)
Try verifying that you’ve released all connection resources (my concern is I don’t see the System.Net.WebResponse object getting a Close() call in your code snippets). The fact you’re seeing delays in the third request sounds like you’ve maxed out on the historical default 2 concurrent HTTP connections limit per domain / proxy.
I thought something similar in that regard as well that perhaps connections not closing.
Turns out, once we removed the PATCH calls from the pipe, I can query as many times, back to back, w/o issue.
So, it may be that the PATCH call itself is the thing not closing. Which would be very odd, but I can’t rule it out without a test on it.
Going to try that next time we have changes and put the PATCH back in the pipe and see if related to that or still suspecting something wrong with the PATCH call on the Zoom side gumming up the Session.