-
Notifications
You must be signed in to change notification settings - Fork 15
Conversation
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.
Looks good, just a few small comments. Do these tests pass at the moment?
Is it deliberate that there aren't tests that go over multiple hops (other than through the bootstrap node) anymore?
I think the way it is is fine, but have you considered a templated version of this test that just lets you specify the types of node0 through node3 and then call a function to run the test? I'm not very familiar with mocha so I don't know if that's tricky or not.
test/kad-dht.js
Outdated
}, callback) | ||
} | ||
|
||
const getNodeId = (node, callback) => { |
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.
Maybe call this getBootstrapAddr?
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.
Better naming yes, I will change it!
Hey @jhiesey Thanks for your help.
The tests pass locally if you change the following here ( start (callback) {
this._running = true
this.network.start((err) => {
if (err) {
return callback(err)
}
this.randomWalk.start(1, 100)
callback()
})
} Attention, this is not an appropriate change, as we should use the
I would like to create the tests with multiple hops as they were before. However, I don't know how to create a test in that format. The previous implementation of that format connected all the peers in a sequence. That way, the test was running successfully with the DHT disabled, so I believe that it was not a valid test. If you have any network suggestion to achieve that, I would like to add it!
I will have a refactor on this later, this is just a WIP for now, and before getting it ready for merging, I will try to reuse the most of the duplicated code. |
41cf41d
to
62600d8
Compare
38730b9
to
18ae27b
Compare
DHT interop tests look good. We need to get ci green before this is good. If there are flakey, unrelated tests we should get a PR to resolve those. Right now the job history for this PR has no successes https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Finterop/activity?branch=PR-36 |
@jacobheun in the last time that I ran the tests all were ok for the DHT tests, and the ones that failed were due timeouts: https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Finterop/detail/PR-36/9/pipeline/361 This way, I wanted to have feedback about the PR before trying to have the all CI green. |
0a37a7e
to
36285ce
Compare
1fe3d4c
to
2b576c5
Compare
@vasco-santos mind rebasing master onto this PR and test it with js-ipfs master? |
@vasco-santos what's the status of this? Can we get CI green and merge? |
2b576c5
to
edebc11
Compare
Now we are able to also add the libp2p options through the I will work on getting this updated with green CI |
1e93916
to
afc2267
Compare
@alanshaw this should be ready to go. What do you think? |
@vasco-santos mind rebasing master to confirm that CI is still green for clean merge? |
afc2267
to
a6d7b31
Compare
ready to go @daviddias |
@@ -3,7 +3,7 @@ | |||
|
|||
// require('./exchange-files') | |||
// require('./pubsub') | |||
require('./kad-dht') | |||
// require('./kad-dht') |
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.
This means it is not being tested. Is that intended?
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, more info: #36 (review)
I can have a look after to that issue with id()
, but I think that it should not be a blocker for this. I can create an issue to track it, as I think it is better to have these tests in now, than have nothing
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.
|
||
callback(null, res.addresses[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.
This function is a tad misleading. All it does is extract the first listing address of a node. Perhaps rename to getNodeAddr?
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.
Yeah, agree! I will change that!
done() | ||
}) | ||
}) | ||
}) |
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 only tests the bootstrap with a JS Daemon, should be tested symmetrically (i.e. with go being the bootstrapper)
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 not sure if I understand your comment. But, I think I have those tests in the suite tests below
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 see now below that the inverse happens
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 don't see any tests for situations where it is expected to fail, for example: two disjoint networks exist, seeking in one side succeeds and in the other fails, then, when both connect, seeking in both side succeeds
before(function (done) { | ||
this.timeout(70 * 1000) | ||
const peersToSpawn = 3 | ||
const bootstrap = bootstrapAddr ? [bootstrapAddr] : [] |
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.
In which case will bootstrapAddr not be available?
spawnJsDaemon(bootstrap, (err, node) => { | ||
expect(err).to.not.exist() | ||
nodes.push(node) | ||
next(err, node) |
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 pass err
here if it won't exist? Also, why pass node if you don't use the results out of the times call?
} | ||
cb(null, peers.length === peersToSpawn) | ||
}) | ||
} |
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.
This function seems to only be testing if the first node is connected to all the other peers. It means that either:
- The name testDhtReady is incorrect
- It is creating a full mesh which will then defeat a bit of the purpose of testing the DHT
done() | ||
}) | ||
}) | ||
}) |
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 see now below that the inverse happens
it('should get from the network after being added', function (done) { | ||
this.timeout(60 * 1000) | ||
|
||
addFileAndCat(nodes[1], [nodes[2], nodes[3]], data, done) | ||
}) | ||
}) | ||
}) |
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.
@vasco-santos I believe the tests above would be better if the tests were described through which nodes play which role (who is the node providing the content, who is the node fetching the content, who is the node bootstrapping the network, who are the other nodes) and make it just a simple config rather than hard wiring things by hand in every test.
What do you think?
}) | ||
}) | ||
}) | ||
|
||
describe('a Go node in the land of JS', () => {}) | ||
describe('hybrid', () => {}) | ||
describe('kad-dht with connections per 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.
What does it mean "with connections per peer"?
addFileAndCat(nodes[2], [nodes[3]], data, done) | ||
}) | ||
}) | ||
}) |
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.
Again, this batch of tests could be more clean if instead of c&p the tests, they were only written once and then called multiple times with the different node configurations
Adds additional tests from #36 as well as some extras requested in the PR comments. Refs: ipfs/js-ipfs#3905
Superseded by #376 |
This PR needs the following changes: