Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

fix: update dht responses #389

Merged
merged 3 commits into from
Dec 7, 2018
Merged

fix: update dht responses #389

merged 3 commits into from
Dec 7, 2018

Conversation

vasco-santos
Copy link
Contributor

@vasco-santos vasco-santos commented Nov 9, 2018

In the context of the ipfs/js-ipfs#856 and ipfs/js-ipfs-api/pull/890

@ghost ghost assigned vasco-santos Nov 9, 2018
@ghost ghost added the in progress label Nov 9, 2018
@vasco-santos vasco-santos force-pushed the fix/update-dht-responses branch 4 times, most recently from 09703c3 to bdb6563 Compare November 10, 2018 23:23
@vasco-santos vasco-santos changed the title [WIP] fix: update dht responses fix: update dht responses Nov 11, 2018
expect(err).to.not.exist()
// TODO upgrade the answer, format is weird
expect(peer[0].Responses[0].ID).to.be.equal(nodeB.peerId.id)
expect(res.Responses[0].Addrs).to.deep.include(nodeB.peerId.addresses[0])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is deep necessary - the values are just strings right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please fix the object that is returned here to not have go-style uppercased first letter properties? - for consistency with the rest of the API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to http api docs, the addrs is an array of addresses. that's why I am using the deep.include.

Changed the uppercase letter. However, the inconsistencies will have to be solved in ipfs-api in ipfs/js-ipfs-api#890. go-ipfs sends the uppercase style, and js-ipfs (aiming to have its core implementation compliant with this interface) must send its response in lowercase. As a result, ipfs-api using js-ipfs will receive the lowercase ones. I added the logic to deal with this inconsistency in the ipfs-api PR, but I am not sure if it is the better approach in this case.

js/src/dht/findpeer.js Show resolved Hide resolved
@@ -60,7 +60,7 @@ module.exports = (createCommon, options) => {
},
(cidV0, cb) => nodeA.dht.findprovs(cidV0, cb),
(provs, cb) => {
expect(provs.map((p) => p.id.toB58String()))
expect(provs.Responses.map((p) => p.ID))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please fix the object that is returned here to not have go-style uppercased first letter properties? - for consistency with the rest of the API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation or implementation for dht.findprovs needs to be updated - provs is not an array of PeerInfo instances.

https://github.com/ipfs/interface-ipfs-core/blob/master/SPEC/DHT.md#dhtfindprovs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Copy link
Contributor

@alanshaw alanshaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, just one small change

@@ -55,12 +55,12 @@ module.exports = (createCommon, options) => {
waterfall([
(cb) => nodeB.object.new('unixfs-dir', cb),
(dagNode, cb) => {
const cidV0 = new CID(dagNode.toJSON().multihash)
const cidV0 = new CID(dagNode.toJSON().hash)
nodeB.dht.provide(cidV0, (err) => cb(err, cidV0))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

object.new now returns a CID

@alanshaw alanshaw merged commit c4bea6f into master Dec 7, 2018
@alanshaw alanshaw deleted the fix/update-dht-responses branch December 7, 2018 10:21
@ghost ghost removed the in progress label Dec 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants