Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix using signaling settings while being refetched
When the external signaling server returns the error "token_expired" the signaling settings are fetched again. However, if there are further requests and "token_expired" is returned again the previous fetch is canceled and a new one started instead, which caused the settings to be temporary set to "null". The signaling settings are expected to always be an object, so setting them to "null" could cause an error if they were used during that time (for example, during a reconnection, which caused the signaling object to "hang" and not do any further connection attempt). Preventing the settings to be nullified is only half of the story, though; "token_expired" can be thrown when trying to connect, and errors thrown when trying to connect cause a reconnection attempt. This could end in a reconnection loop, as each "token_expired" error would cause another fetch of the settings, cancelling the previous fetch and thus preventing the settings to be updated, and as the previous settings would be still used any connection attempt would end again in another "token_expired" error. To solve all that now any connection attempt done after receiving a "token_expired" error is deferred until the signaling settings were updated. Note that the previous signaling settings are kept to ensure that a signaling object is always available, even if outdated. However, any usage of the outdated signaling settings is expected to cause a "token_expired" error to be thrown; right now that only happens during connections, so only that code needs to wait for the settings to be fetched again. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
- Loading branch information