Skip to content
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

use_websocket_with_options, unintuitive reconnection_limit and unreliable reconnection #41

Closed
Madoshakalaka opened this issue Feb 23, 2024 · 1 comment · Fixed by #42

Comments

@Madoshakalaka
Copy link

Madoshakalaka commented Feb 23, 2024

when reconnection_limit is set to None (or left as default), it will be set to 3. This number is not reflected in the docs and only exist in the code.

I think if it's set to None, it should allow infinite many retries.

Also, it makes the reconnection behavior very confusing. I don't know if it's a browser feature (I use Chrome), either connection seems to always fail when the tab is not active, or the timeouts are not executed when the tab is not active ,see this. For me, on production server, the connection does naturally break every now and then, so it is as if the websocket gets stuck at a disconnected state when I put the tab on the background for a few minutes and switch back to the tab.

I forked the code and removed the reconnection_limit altogether and it worked for me well. For any one else who have this issue, setting reconnection_limit to u32::MAX could be a temporary fix.

@jetli jetli closed this as completed in #42 May 26, 2024
jetli added a commit that referenced this issue May 26, 2024
* fix use_websocket reconnect_limit defaults to  for infinite retries, fix #41

* release 0.3.2
@Madoshakalaka
Copy link
Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant