go-waku
go-waku copied to clipboard
bug: stop running waku node, then create a new node and start it raise a lot of warning logs
Describe the bug
I'm debuging the behaviour of network offline and online. When network resumes, I call the wakuNode.stop to stop the running node, then create a new node and start it, a lot of warning logs comes out in console take full of my screen,
2024-01-05T11:18:16.287+0800 WARN pubsub [email protected]/tag_tracer.go:157 error bumping delivery tag: no decaying tag registered for topic /waku/2/default-waku/proto
To Reproduce Steps to reproduce the behavior:
- Go to https://github.com/threeproto/wachat and use
report-warningbranch - Install wails
https://wails.io/docs/gettingstarted/installation - Run wachat app with
wails dev - Close your wifi, then open it again
- See console log
Expected behavior No such logs. And call wakuNode.stop is complete to clean the resource and ready to start a new one.
The log looks similar to what we have seen during a unit test failure as reported in #658 . Are you seeing any functional issue due to this? Never thought this causes a functional issue, but atleast we know the specific scenario when this is occurs.
Go to https://github.com/threeproto/wachat and use
report-warningbranch
BTW, cool sample app built on go-waku. If you plan to maintain it, then you may want to mgirate it to the public waku network by using clusterID as 1 and not use default pubsubTopic.
Also, nice to know of this wails framework to build go based frontends. Will give it a try when i get time :)
Close your wifi, then open it again
~~Curious to know how you are detecting node went offline (that too quite quickly)~~
NVM, figured it out. You are using HTTP to google as a mechanism to find out.
Close your wifi, then open it again
An unrelated question: any specific reason you bringing down and restart wakuNode when network switches from offline to online? You can leave it as is, and when network comes back online connections get established automatically. Only thing you may want to do in your app when connection state changes is to fetch missing messages using Store protocol from a store node.
Are you seeing any functional issue due to this?
No functional issues so far, other than missing important logs.
If you plan to maintain it, then you may want to mgirate it to the public waku network by using clusterID as 1 and not use default pubsubTopic.
Yes, building a small and functional showcase app is main target of this repository. This will help me make this doc.
any specific reason you bringing down and restart wakuNode when network switches from offline to online?
When I test go-waku/chat2 and wachat, the waku node disconnect notification happens after I shutdown the network for more than 20 seconds, and I start the network again, if not restart waku node, waku node auto reconnect happens after another maybe 20 seconds. This makes me feel the disconnect and reconnect is pretty low efficiency and unstable. Or maybe the timeout can be configured, and potentially improved? @chaitanyaprem
When I test go-waku/chat2 and wachat, the waku node disconnect notification happens after I shutdown the network for more than 20 seconds, and I start the network again, if not restart waku node, waku node auto reconnect happens after another maybe 20 seconds.
Do you have logs for this case? I am wondering what might be causing soo much delay. One thing could be the peer connection backoff which keeps increasing if connections keep failing. @richard-ramos is working on addressing this as part of https://github.com/waku-org/go-waku/issues/425. Once that is addressed, this delay should go down.
At first look, this seems to be like something is not cleanedup properly at pubsub level that is causing this. Will take a deeper look to see how this can be resolved.
Not in priority, close it for now.