-
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
base: master
Are you sure you want to change the base?
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)
} as unknown as ConnectionManager, | ||
{} as unknown as PeerManager, | ||
options.libp2p |
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 doesn't typescript comply here/why does it expect an unknown
typecase? :(
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.
it is because mock is partial and there are two ways - mock everything or type casting
since test is a controlled env - type casting is good 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.
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.
screen shot is broken
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.
|
||
import { PeerManager } from "./peer_manager.js"; | ||
|
||
describe("PeerManager", () => { |
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.
should we add new tests for the PeerManager?
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! But in order not to overcomplicate it even further (now there are 4 PRs) - I will make follow up with them
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.
would be good to add tests in the same PR introducing the functionality
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
|
||
private async onPeerConnected(_event: CustomEvent<PeerId>): Promise<void> { | ||
// TODO(weboko): use config.numOfUsedPeers here | ||
if (this.peers.length > 0) { |
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.
A comment above the function to explain this check would be helpful
} | ||
|
||
this.peers = await this.peerManager.getPeers(); | ||
await Promise.all(this.peers.map((peer) => this.subscribe(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.
similar to above, a comment would be helpful. it appears that if a disconnected peer had been used to establish a filter subscription, then this triggers an attempt to resubscribe to all peers?
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
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 want to follow up with integrating HealthManager
back with PeerManager
?
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 should re add tests for the refactored PeerManager
entity
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.
similar comment re not deleting tests
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