fix_: no peers available supporting LightPush protocol after network restored from disabled state #6153
Conversation
Jenkins BuildsClick to see older builds (16)
|
|
The root-cause for issues status-im/status-mobile#21452 / status-im/status-mobile#21394 could not be due to peers not being connected after coming online. In light-clients peers can be connected as required i.e when we want to send messages via lightpush or subscribe to a filter to receive messages. And store nodes are pre-configured and they get connected to as and when we want to do store queries automatically. Hence the discovery of peers and connecting to them need not be done explicitly after coming back online. So far one thing that i had noticed is that the peers that we discover may not be reachable and hence it takes time to make successful connections for filter and lightpush. In order to fix this i had worked on waku-org/go-waku#1244 which would remove peers from local store if they are not reachable. This doesn't solve the problem completely but atleast prevents the node from trying to reuse peers to which connection has failed recently. @qfrank Can you give me the reasoning as to how you identified this as the root-cause for the issues? |
I identified it by debug status backend server ... what I found was: when user back to online from offline(keep offline before login), there's no peers available supporting LightPush protocol ( |
|
BTW, I found |
ah...interesting. got it since bootstrap nodes were not reachable during login and then they were post network is back online. Got it, this fix would definitely address the issue. Thanks for this info, i will start using status backend server to simulate these scenarios. Any instructions on how to use and run it? |
This is also a good point, in case of mobile we can use network connectivity available from device to determine network status and not just peer connectivity alone. Is there a way to access this info from this layer? That way we can use either The |
@chaitanyaprem, do you know if we considered other ways to reliably detect network connectivity in desktop environments? I know there's no multiplatform way to solve this problem, but for such an important problem I would lean on platform specific solutions, going from most reliable to least reliable or a combo of 2 solutions (where checking the number of peers would be somewhere in the middle I guess). Probably such solutions would be better implemented outside the Waku's umbrella (?) @osmaczko @igor-sirotin do you remember past discussions about network connectivity for the desktop app? |
The current approach is more detailed than just simply I am assuming when you say most reliable of solution it would involve some sort of a ping check with a centralized server. if you mean something else, do indicate the same. |
|
@chaitanyaprem thank you for the detailed explanation.
@chaitanyaprem My question/comment was due to a previous comment of yours, quoted here:
We can also leverage the host machine running the desktop app to determine the network connectivity, just as in mobile devices. Or is there something specific about a mobile device you are thinking about? What is hard(er) in devices running the desktop app about detecting network connectivity that's different from a mobile device? My usage of the word reliable wasn't the clearest. By reliability I meant that detecting network connectivity in a device running the desktop app should be reliable and fast, similar to a mobile device. As you outlined yourself, this solution could be complementary to the Waku-only solution using peer connectivity, not a replacement. |
ah, ok.
i don't know if there is any platform agnostic way of doing this. But it may help if we can identify network connectivity outside of waku's purview maybe using some sort of an OS level indication of network not connected. Mobile devices especially running on android/IOS has some phone-home concept which i think is used by status app as well to identify if the device is offline or not apart from waku's own connectivity determination.
got it, and agree that if we can find another alternative way to identify device connectivity in desktop as well it will be helpful. Maybe this can be posted to desktop team to add this functionality into the app. |
qfrank
force-pushed
the
fix/message_not_sent3
branch
from
77bce1b to
4361cb2
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #6153 +/- ##
============================================
+ Coverage 13.89% 60.92% +47.02%
============================================
Files 817 832 +15
Lines 108284 109858 +1574
============================================
+ Hits 15048 66929 +51881
+ Misses 91315 35081 -56234
- Partials 1921 7848 +5927
Flags with carried forward coverage won't be shown. Click here to find out more.
|
qfrank
force-pushed
the
fix/message_not_sent3
branch
from
4361cb2 to
7902aab
Compare
…restored from disabled state
ilmotta
force-pushed
the
fix/message_not_sent3
branch
from
7902aab to
e623029
Compare
fix relate mobile issues: 21452 / 21394, and might also fix part(missing messages) of 21172
relate mobile PR