You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: