-
Notifications
You must be signed in to change notification settings - Fork 61
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
onRelayClientDisconnect/Connect Emitted Twice #116
Comments
Just took a look at my code. For some reason it seems that the I'll keep this in mind, but this isn't a massive bug to me. Having disconnect get called twice isn't a big issue, as it's just closing sockets. |
Since there is no direct way to check the state of the relay connection, we were supposed to use the callbacks. I see BOTH RelayClient.connect and RelayClient.disconnect fire twice. So from the app perspective it is flapping. Good to hear the relay isn't getting unwanted traffic or dropping traffic, so I can agree this is lower priority. Here is the more complete log
|
I am having similar problem. Have you solved it yet? |
Looking at this issue again, it looks like I might be trying to reconnect too fast after a load balance event, and the load balance response occurs again, causing a secondary disconnect/connect emission. Not sure what to do about this. Perhaps wait a short amount of time before I attempt to reconnect? Curious what you think @bobwith2bees |
I would ask the team in charge of the load balancer for their opinion. Also make sure they are aware in case this is related to a setting on their side. In short - get an agreement on expected client behavior. As far as well behaved clients on receiving a load balancer notification - you should consider a truncated exponential backoff algorithm that also implements some randomization. You want to avoid having all the Flutter clients become synchronized and hit the load balancer at the same time. This could occur if there was an outage and the load balancer had to drop multiple clients at one. Some links on the topic, but I don't have a go-to solution at the moment |
Update on behavior as of 2.1.4 release:
I use the onRelayClientConnect event to re-read in all the active signing sessions for that relay connection. I would expect any children sign client sessions to be re-established when the peer connection is restored. Not sure if the sign client sessions issue is related. But it appears to be a possible cause for for #176 #176 (comment) |
@quetool - Since you were looking at older bugs. ;-) The signing session re-connect after the 7 day expiration timer appears broken. I asked in #176 (comment) how one might code a workaround, but there has been no update. I assumed this was introduced with the connection logic changes, so I did not enter a separate bug. Issue can be reproduced by connecting one or more wallets then waiting 7 days. |
Thanks @bobwith2bees , I'll look into this ASAP! |
The connection retry logic or the load balancer is causing a short lived connection every other connection.
I haven't verified on the wire if this is hitting the relay, but the onRelayClientDisconnect and onRelayClientConnect are firing. I can see this on IOS and Android. And the connections used to be ~300 seconds reliably. Not sure if the load balancers are being tuned or the recent relay work is the root cause.
With walletconnect_flutter_v2: ^2.0.12
with the previous release walletconnect_flutter_v2: ^2.0.11. It dwelled a bit longer.
The text was updated successfully, but these errors were encountered: