Waku2 Issues === ### Connected / disconnected state It took up to 3 minutes for go-waku to disconnect the peers once the machine went offline. Since desktop determines if it's connected based on the number of connected peers, the app appeared to be online for 3 minutes, with this state being incorrect. **Fix**: each peer is pinged every 10 seconds. If the ping fails 2 times consecutively, the peer will be automatically disconnected. This means that once the node is offline, it will take ~20 seconds to notice it is disconnected - https://github.com/status-im/go-waku/pull/168 - https://github.com/status-im/status-desktop/pull/4167 - https://github.com/status-im/status-lib/pull/117 - https://github.com/status-im/status-go/pull/2442 --- ### Failure to connect to a store node When login in, all the store nodes from the waku2 fleet are pinged and a store node is chosen randomly depending on the ping time. We noticed that when [`16Ui...97bUZ`]("/ip4/134.209.139.210/tcp/8000/wss/p2p/16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ") is chosen, it fails to return messages, with the error: `short buffer` which is emitted when the number of bytes in the response is less than the expected ``` INF 2021-11-24 13:36:59.343-04:00 Requesting messages from topics="mailserver model" tid=1048308 file=model.nim:166 mailserver=16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ 2021-11-24T13:37:00.009-0400 ERROR wakustore store/waku_store.go:519 could not read response short buffer ERR 2021-11-24 13:37:00.010-04:00 rpc response error topics="rpc" tid=1048308 file=core.nim:24 result="{\"jsonrpc\":\"2.0\",\"id\":0,\"error\":{\"code\":-32000,\"message\":\"short buffer\"}}" payload=[] methodName=wakuext_requestAllHistoricMessages 16Uiu2HAmPLe7Mzm8TsYUubgCAW1aJoeFScxrLj8ppHFivPo97bUZ is failing to serve historic messages ``` *rramos - Nov24*: I think that when a history node fails to return messages, we should temporarily 'blacklist' that store node, and retry with a different store node. If after a number of retry attempts it was not possible to retrieve the messages, the UI must be notified of this error. **Fix**: the issue was caused due to the connection being limited to transfer 64KB of data, but the message history exceeded that amount of data. The code was changed so the limit used is MaxInt64 (in practice, theres's no limit for the amount of data transferred.) It's worth noticing that the history node attempted to transfer ~4.5MB of data for 4131 messages, which IMO is somewhat concerning, specially in countries where data is costly. @Hanno is creating an issue in nim-waku to track this max amount of data issue and propose solutions to improve the pagination. - https://github.com/status-im/go-waku/pull/168 - https://github.com/status-im/status-desktop/pull/4167 - https://github.com/status-im/status-lib/pull/117 - https://github.com/status-im/status-go/pull/2442 --- ### Running 2 instances of desktop listening to the same port but using different accounts **NOT CONFIRMED** This causes one of the clients to be able to send messages but not receive them. This is probably normal behavior for go-libp2p, and the solution might be as simple as setting a random port number instead of always using port 60000