fix: use correct ticker for all peers ping

[chaitanyaprem]

Description

while going through code, noticed that randomPeersTicker was being over-ridden by allpeersTicker.
this causes peers to be disconnected forcefully every 5 minutes in relay mode

[chaitanyaprem]

while i was trying to capture peer counts and monitor bandwidth usage locally in relay mode, i had noticed peer counts drop to 0 every 5 minutes. while looking in the code for timers that are 5 minutes found that allpeersPingtimer is 5 mins and once i fixed this issue, i am not noticing peer counts drop to 0.

Can't figure out if really peer counts are going to 0 or something else is happening. any thoughts @richard-ramos

Here is the graph of running my desktop instance for about 6 hours and notice that towards the end peer-counts don't drop anymore (after applying this fix).

[chaitanyaprem]

i think i figured out what is happening without this fix, since ticker is being overridden by wrong timer below logic assumes peer ping failed since it has been too long and forcefully disconnects all peers every 5 minutes. This bug causes relay node to keep loosing connectivity every 5 minutes and re-establish connections with peers and will cause message reliability issues.

go-waku/waku/v2/node/keepalive.go

Lines 85 to 91 in 99d2477

	case <-randomPeersTickerC:
	difference := w.timesource.Now().UnixNano() - lastTimeExecuted.UnixNano()
	if difference > sleepDetectionInterval {
	lastTimeExecuted = w.timesource.Now()
	w.log.Warn("keep alive hasnt been executed recently. Killing all connections")
	disconnectAllPeers(w.host, w.log)
	continue

@richard-ramos @kaichaosun @plopezlpz is there a way we can get this fix released into status desktop patch version? otherwise all users will be facing constant disconnections (every 5 minutes they will loose all peers) and hence message reliability issues.

Logs while running status-desktop in relay mode without this fix show the same.

WARN [08-20|09:19:23.652|github.com/waku-org/go-waku/waku/v2/node/keepalive.go:87] keep alive hasnt been executed recently. Killing all connections 
WARN [09-04|09:28:04.044|github.com/waku-org/go-waku/waku/v2/node/keepalive.go:89]  keep alive hasnt been executed recently. Killing all connections 
WARN [09-04|09:33:04.046|github.com/waku-org/go-waku/waku/v2/node/keepalive.go:89]    keep alive hasnt been executed recently. Killing all connections 

[kaichaosun]

There is release branch for go-waku and status-go, cherry pick the commit and maybe tag QA team for version upgrade possibilities.

https://github.com/waku-org/go-waku/tree/status-releases/2.30.x

[chaitanyaprem]

There is release branch for go-waku and status-go, cherry pick the commit and maybe tag QA team for version upgrade possibilities.

https://github.com/waku-org/go-waku/tree/status-releases/2.30.x

since 2.30 is released, was not sure if this branch is still used or not.

[richard-ramos]

Lets cc: @iurimatias, because i'm not sure what's the approach used in desktop for patch releases!

[iurimatias]

Lets cc: @iurimatias, because i'm not sure what's the approach used in desktop for patch releases!

We follow semver, we can do a 2.30.1 release for this (after testing), starting with 2.30.1-rc1.

[chaitanyaprem]

Lets cc: @iurimatias, because i'm not sure what's the approach used in desktop for patch releases!

We follow semver, we can do a 2.30.1 release for this (after testing), starting with 2.30.1-rc1.

thanks...is there a branch in status-go and status-desktop already for 2.30.1 or we need to create one for this alone? if there are any other important fixes, we can include them as well and then make a 2.30.1 release.

[iurimatias]

Lets cc: @iurimatias, because i'm not sure what's the approach used in desktop for patch releases!

We follow semver, we can do a 2.30.1 release for this (after testing), starting with 2.30.1-rc1.

thanks...is there a branch in status-go and status-desktop already for 2.30.1 or we need to create one for this alone? if there are any other important fixes, we can include them as well and then make a 2.30.1 release.

I'll prepare a PR / branch after a meeting. the QAs will need to test it etc..

[iurimatias]

@chaitanyaprem @richard-ramos is this going to be merged first? or should I point it to this branch to test?

I like @kaichaosun suggestion to merge it to release/2.30.x (besides master) it makes everything more consistent (and stable), I recommend that

[iurimatias]

I'll create the PR for release/2.3.x