Start relay protocol on wakunode2 #446
Conversation
waku/v2/node/wakunode2.nim
Outdated
| @@ -416,6 +419,13 @@ proc mountRelay*(node: WakuNode, topics: seq[string] = newSeq[string](), rlnRela | |||
| # TODO currently the message validator is set for the defaultTopic, this can be configurable to accept other pubsub topics as well | |||
| addRLNRelayValidator(node, defaultTopic) | |||
| info "WakuRLNRelay is mounted successfully" | |||
|
|
|||
| if node.libp2pTransportLoops.len > 0: | |||
There was a problem hiding this comment.
Hm, is this the idiomatic way of doing this? How does it work in nimbus-eth2?
There was a problem hiding this comment.
nimbus-eth2 follows a strict order where the protocol is always mounted before starting the node. In fact, they mount GossipSub when creating the eth2 node, implying that my assumptions in the description above don't hold for them. We may consider doing the same (perhaps only for WakuRelay?), but that would require a fairly significant change in approach.
Seeing if related futures are set to know if the protocol/node has started doesn't feel idiomatic, but is at least not without precedent - this is similar to how GossipSub itself avoids a "double" start. A cleaner alternative, of course, is to just add started state.
There was a problem hiding this comment.
In fact, I've changed this now to rather use an explicit started state variable (31700c8). Lmk if you have strong feelings about either the order in which we mount/start or what type of state we keep.
This PR fixes #445
It ensures that
relayprotocol, and the underlyinggossipsub, is started on awakunode2.This fix assumes the following:
nodecan be started andrelayprotocol mounted in any order.relayis mounted, it should start if and only if thenodewas already started. Otherwise it should start onnodestart.Note: I'm not sure if the original intention was to be somewhat more strict in terms of the ordering above, e.g. that protocols should always be mounted before the node starts listening. In our current examples, tests and scripts, the
mount()<->start()order seems to be interchangeable, which allows for mounting protocols on live nodes.