Description
In the Web SDK, you are use both browser localStorage and sessionStorage to keep some data.
As you may know, local storage and session storage have some differences, especially the following ones:
local storage is shared acrross all browser tabs and is kept even after closing a session in the browser (closing the browser window)
session storage is per tab only (private session) and cleaned up after closing the related tab session / browser window.
This is just a reminder, now comes the issue.
After doing a downgrade of the web SDK (from 2.4.5 to 2.4.0) for any reason (we had for internal reason to temporary downgrade it on our application for a while and therefore we found that issue), when you join a zoom meeting, you cannot click on the Audio join by Computer button.
Well, you can click but this trigger a javascript error complaining about the fact that there is an already existing same key in the local storage when trying to put something on the session storage (for same key)
This is the local & session storage for the application, you can see that the zoom SDK stores things in here. You may have more or less values depending on your last browser storage data clean up.
The fact that same data is saved in both local & session storage seems to be an issue for the Zoom Web SDK after a downgrade. This does not seems to happen when upgrading the zoom web SDK.
This is very annoying and prevent any users to be able to join with their audio on any meeting after a downgrade, without clearing the cookies / site data manually.
Thank you for the tag @nvivot! I can see how having to manually clear the cookies/site data after downgrading the SDK version can be annoying. Happy to bring this use case up to the SDK team for consideration. Before doing so, would you be able to provide more details about this use case? How frequently are you having to temporarily downgrade your application? What problem does temporarily downgrading the SDK solve?
We usually don’t have to downgrade the web SDK, but that can time to time happen when we missed something during our UAT and a blocking (enough) issue happens on production after a release.
This is the first case we had to in two years, and not because of the SDK (and its associated tests) but because of an issue within our application (both the SDK upgrade and internal changes came in same release)
So not that often, but since we are deploying this to kubernetes and have automation tool to within a few seconds / minute rollback to a previous release, it’s a blocking case.
The alternative is to publish a new release with just the SDK upgrade without the breaking changes of the application and that’s what we had to do after all, but this requires time and would not prevent the worse case where the issue comes from the SDK and we really have no other choice than downgrading it.
Note: not all users faced this issue. We have instructors for example using our application from chrome boxes with an automatic session clearnup every day. They did not have the issue since we wipe out their cache data automatically.
But for real clients we have not the hand on their environment, this is really an issue as it would depends on the time of their last lesson took with their browser, whether they cleared cache in between their lessons, etc… which is never the case for 70% of people our there.
We appreciate you forwarding this case to the team. Thank you.
Thank you for taking the time to provide these additional details regarding the behavior experienced when downgrading the SDK version. I can see how this current downgrade workflow can impact the user experience for clients that you are unable to wipe out their cache data automatically. I’ll share this with the team and see what their thoughts are on this edge case. Please let me if you have already reported this edge case to support? If so, please share the ticket number with me as well.
