-
Notifications
You must be signed in to change notification settings - Fork 45
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/autoshard filter #723
Conversation
Jenkins BuildsClick to see older builds (106)
|
@jakubgs , some CI checks are failing due to 500 error. Tried re-running it, still seeing failure.
|
Fixed. |
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.
Looks good, however, where pubsub topic is marked as Optional in the different READMEs and comments, I think we need to add add some note indicating that pubsub topics are considered mandatory when used with named and static sharding, and not when using autosharding (in the case of the READMEs), and expand more on what does it mean for the pubsub topic to be optional?
Makes me wonder if we should convert ContentFilter
into an interface and implementations both for named/static sharding and autosharding, with the former requiring the PubsubTopic? i.e.:
// Names are just an example
contentFilterA := NewAutoshardingContentFilter("theContentTopic)
subs, err := node.FilterLightClient().Subscribe(ctx, contentFilterA)
contentFilterB := NewContentFilter("thePubsubTopic", []string{"theContentTopics"...}
subs, err := node.FilterLightClient().Subscribe(ctx, contentFilterB)
The idea would be to allow the pubsub topic to be optional, but make it harder for the library user to use the pubsub topic incorrectly.
I left also some additional comments and questions
Will update Readme's. I do like the idea of making contentFilter in a way so that people cannot misuse. But, rather than making this change within the core filter code, it would be better to do it at API side. Otherwise it won't give us flexibility we want within core code. WDYT? |
Sounds good 🚀 |
Will take care of this in a separate PR, as this PR has been open for too long and has too many merges. |
Description
Update Filter client API to work with Autosharding logic. #673
A client user can specify the following options when subscribing/unsubscribing from filter.
Note: In order to not bloat this PR, optional pubSubTopic handing in MessagePush shall be done in separate PR.
Changes
Tests
Added new Filter tests to validate Autosharding.
Same can be executed by running below command in
waku/v2/protocol/filter directory
go test -testify.m TestAutoShard