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.
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:
Here is a screenshot (same client just few minutes after) of resource load during a successful 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)
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 ?
1.7.10 and 1.8.0
To Reproduce(If applicable)
Not easy to reproduce as it depends on the context.