You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Presently Store gets one peer to query messages here.
Recently it was improved so that if user sets in config which node to query - it will be prioritized - here.
But in case it was not set or the node was disconnected by various reasons, we will try to get any one available - here.
It becomes tricky when we have multiple nodes available as in that case we will take some random peers that are available - here.
This is the problem when we change it to be deterministic and only take the same peer that is available (i.e first one from those that a node is connected to) - it can be seen in context of this test.
In this test we see that js-waku can be connected to one node that has some messages and, at the same time, to another node that has other messages. If peer selection is same across requests to peerManager - we will have only half of the messages.
To fix this, ideally, we want to be able to know which shard a peer is connected to and query it based on Store request.
User Story
As consumer, I want to query arbitrary amount of shards without manually specifying a peer.
As consumer, I want to set particular peer to for Store query, so that I am sure data will be found.
Proposed Solution / Feature Design
We need to investigate if it is possible to know what shard a peer listening to so that we would be able to match to users query.
As a fall back we need to add peer as parameter to query method so that consumer would be sure about which node is queried.
Optional: Diagram or Draft of Design
Notes
No clear deliverable to attach this task to yet.
The text was updated successfully, but these errors were encountered:
Description
Presently
Store
gets one peer to query messages here.Recently it was improved so that if user sets in config which node to query - it will be prioritized - here.
But in case it was not set or the node was disconnected by various reasons, we will try to get any one available - here.
It becomes tricky when we have multiple nodes available as in that case we will take some random peers that are available - here.
This is the problem when we change it to be deterministic and only take the same peer that is available (i.e first one from those that a node is connected to) - it can be seen in context of this test.
In this test we see that
js-waku
can be connected to one node that has some messages and, at the same time, to another node that has other messages. If peer selection is same across requests topeerManager
- we will have only half of the messages.To fix this, ideally, we want to be able to know which
shard
a peer is connected to and query it based onStore
request.User Story
shards
without manually specifying a peer.Store
query, so that I am sure data will be found.Proposed Solution / Feature Design
shard
a peer listening to so that we would be able to match to users query.peer
as parameter to query method so that consumer would be sure about which node is queried.Optional: Diagram or Draft of Design
Notes
No clear deliverable to attach this task to yet.
The text was updated successfully, but these errors were encountered: