Description:
It has come to my attention that, in the course of configuring a custom API to store information about our Zoom sessions, we are seeing that different users in our org using our subscription account to access our custom video chat solution may end up with the same Zoom ID over different sessions. We have not seen this in the same session, but we have called client.join() with different signatures, different usernames, to different topical rooms from different browsers AND computers over the course of days and have seen a few IDs be repeatedly (but not concurrently) assigned.
We raised this notice before but we were instructed that it was highly unlikely. This “recycling” however has been observed by our team recently again. We have seen it with more than one ID - in particular there seems to be one ID that is extremely likely to be reassigned and another ID that usually comes up for the second joiner.
While it may be difficult to reproduce, a possibility is that some aspect of the system that generates IDs for a particular account’s users is somewhat deterministic and is prone to recycling. It may be unlikely to happen in a system with constant use, but could pop up more frequently if the account in question returns often to a zero-active-user state & is frequently starting at the beginning of an algorithm of ID assignments.
Which Web Video SDK version?
1.1.0, but also 1.0.3 exhibited this.
To Reproduce
You will need to set your software to allow end users to see their own ID and, perhaps, the participants in a meeting. The frequency is intermittent, but I’ve seen it fairly consistently.
Using an account that is not in use, simply have 2-3 people join a meeting and take note of their assigned IDs. Allow everyone to log off.
Repeat an hour later (ensuring that the account is not used by others in the meantime) and compare the second-time assigned IDs to the first batch. You may use entirely different connection information, including different user names and a different topic.
We have sometimes seen it as soon as 15 minutes.
Devices:
Observed on heterogenous systems. Most are Ubuntu 20.04 LTS, running Chrome 91.0.4472.114 (64bit) on assorted PC hardware. Can similarly occur with Firefox 89.0.2 (64-bit) on the same OS/hardware. One of our rotating clients is on Win10 with the same Chrome version as above.
Additional context
It’s worth restating that this isn’t a “bug” to us, but clients or secondary APIs cannot assume that there is a practically zero probability of any two users (in different meetings at different times) being assigned the same ID, and cannot depend on it. Any custom client user tracking system must assume that User 2 can get a re-used Zoom ID after User 1 has been assigned it for a different connection (but not concurrently). It may not happen in certain scenarios, but we’re unclear if/why there are exceptions. We have made sure that none of our logic depends on Zoom IDs being uniquely assigned and non-repeating. The repeat-ID tendency has not prevented any of our users from using client.join() successfully.