Closed richard-ramos closed 1 month ago
cc @gabrielmer who is doing some refactoring around that.
I am also aiming to improve this logic with https://github.com/waku-org/nwaku/pull/2859
I am wondering if it is happening because of default config if shards are not specified
We did enable autosharding for any cluster in https://github.com/waku-org/nwaku/pull/2505
The way it works is by activating it with the amount of shards passed with the --pubsub-topic
parameter
The idea is in my PR deprecating the --pubsub-topic
parameter, introduce a new flag named something like --network-shards
where users in clusters different than TWN set how many shards are in the network and that number will be used when running autosharding's algorithm
@richard-ramos WDYT? given that autosharding is enabled by default in every cluster, is there any bug in here? not sure if to whether to close this issue or if there's some action item
Let's close this. I modified go-waku so it mounts metadata protocol regardless of clusterID being 0 to match nwaku's behavior.
Problem
This might not be a bug but intended behavior, but just in case: While testing interop between go-waku and nwaku for storev3, I noticed the following:
(Notice that shards 0 to 7 are being added automatically.
Please clarify whether this is the intended behavior. In go-waku the tests use content topics with random format, so assuming autosharding is getting enabled by default for all clusterIDs, maybe changes must be done to ensure we use the correct format?, as well as ensure the format for the content topics in status-go is also supported