-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: create default shard info, update tests #2085
Conversation
@@ -228,6 +228,7 @@ export function contentTopicsByPubsubTopic( | |||
*/ | |||
export function determinePubsubTopic( | |||
contentTopic: string, | |||
// TODO: make it accept ShardInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To follow up: #2086
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Approving to unblock - however a few comments I think should be addressed before we merge this
* | ||
* You cannot add or remove pubsub topics after initialization of the node. | ||
*/ | ||
pubsubTopics?: PubsubTopic[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd vote to remove this completely as well. We are assuming that developers might still want to use named sharding, but a complete deprecation looks like the right step ahead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also thinking the same - but I changed my mind when recalled scenarios of some of our consumers that do not use any of our fleets, not to mention TWN.
So we need to continue providing support for pubsubTopics
in order to allow them soft transition (or for some not to use our fleets at all).
if (!options.shardInfo) { | ||
options.shardInfo = DefaultShardInfo; | ||
} | ||
|
||
const shardInfo = options.shardInfo | ||
? ensureShardingConfigured(options.shardInfo) | ||
: undefined; | ||
|
||
options.pubsubTopics = shardInfo?.pubsubTopics ?? | ||
options.pubsubTopics ?? [DefaultPubsubTopic]; | ||
options.pubsubTopics = options.pubsubTopics ?? shardInfo?.pubsubTopics; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here in case shardInfo
exists, we have redundancy updating shardInfo
as well as pubsubTopic
with same information. Comment above about complete deprecation of this property looks like the clean direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good point but I don't think we should get rid of pubsubTopics
for internal use because we:
- have tight coupling to it in our code base;
- libp2p itself uses it a lot;
- it's native to gossipSub so anyway we face the need to refer to it one way or another;
…2083) * changing default pubsub topic to its static sharding version * keeping RFC's Waku Message test vectors * reverting change in changelog * setting pubsub topic when creating nwaku node * adding shardInfo to runMultipleNodes call * adding shardInfo to runMultipleNodes call in lightpush tests * add pubsub topics to nwaku.start * get rid of it.only that remained * fixing compliance tests * setting clusterId to 0 * removing unnecessary fix * adding shardInfo when creating nodes * fixing wait for remote peer tests * fixing peer exchange test * refactor * removing unnecessary variable * feat: create default shard info, update tests (#2085) * feat: create default shard info, update tests * add link * fix tests * remoe only * up tests * up test --------- Co-authored-by: Sasha <[email protected]>
Problem
Named sharding is deprecated.
We need to comply
Solution
pubsubTopic
parameter as a fallback for consumers of the library that do not use The Waku Network or static sharding;DefaultShardInfo
as a fallback that is configured for The Waku Network all shards;DefaultPubsubTopic
;Notes