We sometime have clients who get timeout when performing the join operation on the web SDK to join a meeting.
The timeout is triggered from our application. It’s a customized maximum time setup on our application to perform the join operation. After that time if we have no reply from the join operation we consider there was a problem. Our current timeout value is 90 seconds.
Error
The timeout here is just a symptom (from my investigations and understanding of the Zoom Web SDK)
By monitoring client’s browser activity i could figure that for every failed attempts the WASM libraries are never loaded.
Resources & script are perform in the following order :
app start
js lib loaded + wasm lib loaded + js sdk prepared
zoom signature generated
zoom init() performed
zoom join() performed (not shown on the screenshot as it never returns)
But even if the wasm preload could be performed, it’s done asynchronously so we do not have the ability to verify if it’s correctly performed or not.
Here is a screenshot of resource load during a failed attempt:
I remember that from version 1.7.8 or 1.7.9 (don’t remember which one exactly) you published a fix on the Web SDK to prevent the join operation to continue when WASM libraries are not fully loaded. (to prevent a race condition issue)
Assumption
So i’m currently wondering if this timeout could be the symptom that the join is just waiting for the WASM to be loaded. And if so, why WASM files are not loading for the few first attempts and then suddenly with no changes on client side they can be loaded.
Do you guys have an explanation why the wasm libraries do not load in such case ?
Which version?
1.7.10 and 1.8.0
To Reproduce(If applicable)
Not easy to reproduce as it depends on the context.
The next attempts (few seconds after the failed one, users just leave and login again into our application) were successful and users could join the meeting.
Multiple users got this same error at close times, which means probably a resource availability problem on the CDN.
Do you have insight / feedback about that ?
Pretty annoying and it started to happen more and more frequently since last week
Thanks for reporting this and providing the information in a great detail. Our Web SDK engineers are investigating the issue. I will get back to you once we find the issue. (CS-2321)
Here is a meeting where wasm libraries could not be loaded due to fetch error.
Many unsuccessful attempts and few successful ones for this same meeting from the same user (c_…)
I don’t think anyone is using Zoom SDK in production. This is the biggest issue and it is not at all working. Web Assemblies (.WASM) files take some time to download inside the browser cache. There should be some additional methods which will guaranty that all .WASM files are in the browser cache so that should determine if JOIN() command can be executed.
We have postponed our release 7 more days, we are desperately waiting for the solution. @tommy you are the author of this SDK, so you can solve this issue in a separate early build. You can just expose the timeout attribute for SDK consumer so that we will set a maximum timeout limit or you can just add a new method like “IsInitilized()” and we will check its status before issuing join() method, you people have done that in Xamarin SDK also. There is no other way to find out if all 4 .WASM files are downloaded to the browser cache. Basicall the issue is Join() tries to execute before all 4 .WASM files are avaliable at browser end.
@tommy If you need some testing help, i can provide that. I made this work in Angular, but my solution is not acceptable to our team. What i do is, i put a 75 seconds waiting timer in the ngOnInit() method, during that time all 4 .WASM files are available in the browser cache, so it works. But this 75 seconds wait is killing the purpose.
We are increasing the timeout time. Your idea of exposing the timeout attribute in the Web SDK is a great idea, and I will pass this along to our team.
We also had to wrap zoom join() call with a timeout system to prevent any infinite (or very long) waiting scenario (which happen less and less but still can)
If this is integrated to the SDK we are also interested in as we could remove that logic from our code.
But keep in mind that this will not fix the original issue which is the static resources not being available.
Since we have no feedback from you on that point, we are completely moving to a local static resource solution by copying all WASM / JS / MP3 resources the SDK need from the NPM package to our docker image and then cache everything in between with our public provider service.
I don’t say Zoom is in cause here, but without feedback we had to choose another way to reduce the number of errors sources.
In case you find the original cause of this wasm file not being available, i’m interested in knowing
