-
Notifications
You must be signed in to change notification settings - Fork 976
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
refactor(kad): make Kademlia::add_address
return Result
#4280
base: master
Are you sure you want to change the base?
Conversation
Kademlia::add_address
return ResultKademlia::add_address
return Result
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.
Thanks! This looks good to me :)
It needs a changelog entry and a version bump. Given that this is a breaking change, we'll hold off on merging this for a bit to allow us to batch breaking changes together. Hence, I'll convert this to a draft so that it doesn't get merged accidentially!
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 am in favor of the change. Thanks.
@arsenron Can you fix the CI errors please? We are thinking of cutting a new (breaking) release and thus would like all the queued PRs to be ready for merge :) |
This pull request has merge conflicts. Could you please resolve them @arsenron? 🙏 |
Sure! I will do it today. |
@thomaseizinger Done. But just cargo-deny fails, but it is unrelevant to the updates made by this PR, so I skipped it. |
Great! Yeah good call on that one, we already have a PR queued to fix that :) |
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 noticed an overlap with an upcoming feature that I think we have to discuss before moving forward here. Sorry for the late notice!
pub fn add_address( | ||
&mut self, | ||
peer: &PeerId, | ||
address: Multiaddr, | ||
) -> Result<RoutingUpdateOk, RoutingUpdateError> { |
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.
Sorry that this is only coming up now but I just realized that we have a feature coming up that conflicts with this idea. It is here: #4371
This function will likely be deprecated in favor of a general add_address_of_peer
function on Swarm
. This means, we won't be able to return a specific error there!
In fact, we won't be able to return anything at all.
Thus, I think we should actually change this PR into preparing this API for the above change. Here is what I'd suggest but I am interested to hear your and @mxinden's opinion:
- Mark
RoutingUpdate
as deprecated but retain the current functionality. - Always emit
KademliaEvent::RoutingUpdated
, even for the immediateRoutingUpdate::Success
case - Add a
debug_assert
to theSelfEntry
case. If we attempt to add ourselves to the routing table, this is a programmer bug and should not happen. We can ignore that in production (but should probably emit a fatwarn!
), hence thedebug_assert
. - We already log a warning for the bucket-full case so we can just leave it at that.
This makes this a backwards-compatible change and we can land it right away.
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 missed this as well. I am sorry @arsenron.
Suggestion overall sounds good to me.
Add a
debug_assert
to theSelfEntry
case. If we attempt to add ourselves to the routing table, this is a programmer bug and should not happen. We can ignore that in production (but should probably emit a fatwarn!
), hence thedebug_assert
.
Panicing on invalid user input seems rather drastic. Wouldn't a warn!
suffice in all cases? Also, not as part of this pull request, we should handle the SelfEntry
on the libp2p-swarm
level. We should at least log when a NetworkBehaviour
or user (via Swarm::add_address_of_peer
) wants to report a an external address of a remote peer where that peer is actually the local 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.
I missed this as well. I am sorry @arsenron.
Suggestion overall sounds good to me.
Add a
debug_assert
to theSelfEntry
case. If we attempt to add ourselves to the routing table, this is a programmer bug and should not happen. We can ignore that in production (but should probably emit a fatwarn!
), hence thedebug_assert
.Panicing on invalid user input seems rather drastic. Wouldn't a
warn!
suffice in all cases?
The warn will be there in all cases but pancking in debug builds is fine, no? You didn't validate your inputs correctly in that case.
Also, not as part of this pull request, we should handle the
SelfEntry
on thelibp2p-swarm
level. We should at least log when aNetworkBehaviour
or user (viaSwarm::add_address_of_peer
) wants to report a an external address of a remote peer where that peer is actually the local peer.
True, as part of #4371, we should probably not forward any of these events! cc @StemCll
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.
@arsenron I fixed the merge conflicts for you. Are you still interested in working on this given the above insight?
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.
@thomaseizinger sorry, little busy now, but I will check it a bit later
This pull request has merge conflicts. Could you please resolve them @arsenron? 🙏 |
This pull request has merge conflicts. Could you please resolve them @arsenron? 🙏 |
This pull request has merge conflicts. Could you please resolve them @arsenron? 🙏 |
Removing this from the milestone because the proposed way forward is backwards-compatible: https://github.com/libp2p/rust-libp2p/pull/4280/files#r1333693065. |
Description
This PR makes a clear separation between successful and unsuccessful result of adding a peer to the DHT. It seems to me that it improves ergonomics of the public API.
Notes & open questions
If you agree on this PR, I will add some tests and update examples.
Change checklist