-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
connect through state very temperamental #39
Comments
You are right, restoring the state should use a no-op (but maybe not |
Whatever the smallest request the better (from a speed/BW point of view). We also should add the reconnect option as discussed (so users do not need to re-create the instance to reconnect). |
I am going to update this and say while the current error and complete re-create works 95% of the time, I have found there is 5% of the time where it will not be getting proper events and not throwing an error leading to missed events. I have yet to find a solution to this. |
Thank you for working on this issue. |
Restoring the state seems to work pretty fine for the Skype token but fail with the registration token if it stopped for more than a few minutes. We may need to issue a new registration token (endpoint) to fix this. |
For example calling after awaiting the connect:
then for when connecting doing:
will periodically not connect properly, and will not throw an error either. I have added inside the normal connect T/C:
await api.setStatus("Online");
as if it doesn't connect right this command will fail.
skypeHttp.connect
state resuming should always throw an error if resuming from state does not work (even if we have to make a no-op call after loading state to the skype service to make sure we are all good).The text was updated successfully, but these errors were encountered: