protocols/kad: populate the key field to fix go-libp2p interop #2309
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pradt2
changed the title
pradt2
changed the title
|
Great catch @pradt2! Thank you for both debugging and providing a fix. For the reference, the corresponding Golang logic expecting both a key in the message in and the record: I will need to do some more testing, communicate with the go-libp2p folks and update the specification. I am sorry for the delay. Again, great work @pradt2! |
|
libp2p/specs#373 updates the specification accordingly. @pradt2 would you mind adding a changelog entry to |
|
@mxinden done |
This was referenced Nov 10, 2021
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I had to make this change to get the (predominantly go-libp2p based) IPFS DHT nodes to accept any records issued by rust-libp2p.
I'm a bit surprised that this change has to be made since the key is also present in the Record itself. However, I double checked against the go-libp2p implementation, and there they do indeed set the key both in the Record, as well as directly in the Message.
All tests in the protocols.rs file are commented out, so I didn't bother trying to fit in a test case for this. I hope that's okay.