-
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: improve peer manager and re-integrate to light push #2191
Conversation
size-limit report 📦
|
…s, add getPeers for IWaku
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.
Nice PR! 🚀
Lots happening here.
A few pointers from my side:
- Are we planning to address the TODOs part of this PR, or follow up?
- Do we need to introduce newer tests as we delete the functionalities and respective spec tests?
- How does the peer management work with this PR, considering the overhaul of BaseProtocol, PeerManager and ConnectionManager? Is it stable?
return getPeersForProtocol(this.components.peerStore, [this.multicodec]); | ||
} | ||
|
||
public async connectedPeers(): Promise<Peer[]> { |
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.
Do we still have access to this utility function from elsewhere?
Basically getting the connected peers for a particular protocol
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.
yes, in ConnectionManager
there is method implemented for it
public async getConnectedPeers(codec?: string): Promise<Peer[]>
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.
easier to do
waku.lightpush.connectedPeers()
vs
waku.connectionManager.getPeers(waku.lightpush.multicodec)
im in favor of not removing this
also is a breaking change
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.
why waku.lightpush.connectedPeers()
even needed?
I would assume to be used on the consumer side - but then it's something that we don't expect to be used
whereas waku.connectionManager.getPeers(waku.lightpush.multicodec)
is for internal usage for protocols and shouldn't be used outside
also is a breaking change
agree, this PR is pretty much breaking change as we found out previous things were not working well enough
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.
we have had feedback in the past that convinces us that consumers want to be able to check the information of connected peers on the protocol (cc @vpavlin)
we can add it on the SDK layer instead of the core
layer
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.
we can continue to use ConnectionManager
to provide this API - do you see reason in switching out the use of multicodecs as arg for the function, with the enum type for protocols instead to help DX? (ref: #2191)
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.
we have had feedback in the past that convinces us that consumers want to be able to check the information
that should be tackled by health
state of the node, otherwise I don't see a need for consumers for do waku.lightPush.connectedPeers()
- if that is something they need to do we can tell them:
- do
waku.getConnectedPeers().filter(byMulticodec)
; - expose
connectionManager
so that they can do the same from it;
Back then this functionality was added without clear need.
do you see reason in switching out the use of multicodecs as arg for the function, with the enum type for protocols instead to help DX?
as I explained it in the other comment - connectionManager.getPeers(multicodec)
- will return peers for metadata
and other protocols where as Protocols
is for consumers use and has only LightPush
/Filter
etc.
Just to clarify here - let's not have unnecessary entry points and not needed code. This will be easier for us as to support, bug fix and improve our own code base.
I see us adding one method that does the job and then improving it if we find more evidence.
Of course I might be wrong as to this particular case, but then we can add it once requested.
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.
@danisharora099 let me know what you think.
thank you @danisharora099
absolutely, I was looking at some last week
absolutely again, but I limit this PR to drastic changes + manual validation and dogfooding
explained in the comment above |
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.
did another review
left comments in individual threads
* add message cache to Filter * remove WakuOptions and use only ProtocolCreateOptions * move subscribe options to createLightNode Fitler protocol options * rename SubscriptionManager to Subscription * rename to CreateNodeOptions * add warning * feat: introduce subscription manager (#2202) * feat: inroduce subscription manager * fix: make pipeline succeed (#2238) * fix test * use hardcoded value * update playwright * fix test:browser
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.
nice work! lgtm
primarily comments remaining are around not deleting tests, and adding new tests for new functionalities
Problem
After spending time with project that use
js-waku
we were able to determine entities in the code which behavior can be improve. Among them: PeerManager, ReliabilityManager etc.Solution
For behavior this PR aims to add robustenes to the code by adding new configuration properties and making sure they are enforced.
This PR also re-works
PeerManager
and partiallyRelibilityManager
.Notes