chore: go-libp2p-kad-dht v0.26.1 #10488
Conversation
lidel
changed the title
v0.26.0 missed some commits, checking if icluding them helps with failing helia interop libp2p/go-libp2p-kad-dht#980
go.mod
Outdated
| @@ -51,7 +51,7 @@ require ( | |||
| github.com/libp2p/go-doh-resolver v0.4.0 | |||
| github.com/libp2p/go-libp2p v0.36.2 | |||
| github.com/libp2p/go-libp2p-http v0.5.0 | |||
| github.com/libp2p/go-libp2p-kad-dht v0.25.2 | |||
| github.com/libp2p/go-libp2p-kad-dht v0.26.0 | |||
There was a problem hiding this comment.
go-libp2p-kad-dht v0.26.0 breaks helia-interop (log)
There was a problem hiding this comment.
v0.26.0 was missing some commits, but testing with libp2p/go-libp2p-kad-dht#980 also fails in the same place (log).
Needs analysis. Kubo being able to resolve thing when it is not expected to is a weird regression, I suspect kad-dht client got better somehow, and helia-interop test no longer making sense, may be requiring update.
There was a problem hiding this comment.
Uppon inspection it feels the failing "helia→pubsub→kubo" test is a bit hacky and does not follow what is done is his sibling "kubo→pubsub→helia":
// first publish should fail because kubo isn't subscribed to key update channel
await expect(name.publish(peerId, cid)).to.eventually.be.rejected()
.with.property('message', 'PublishError.NoPeersSubscribedToTopic')
// should fail to resolve the first time as kubo was not subscribed to the pubsub channel
await expect(last(kubo.api.name.resolve(peerId, {
timeout: 100
}))).to.eventually.be.undefined()This is brittle, it calls name.publish when it should not, and likely being prone to race bugs like the one in this PR, likely due to changes in libp2p networking stack.
Since this test is not related to DHT, I think we've hit the brittle surface.
Good news is that there are better ways of confirming that peers are or are not subscribed to a topic.
I've submitted upstream fix in ipfs/helia#584, will switch to it before merging this PR.
switching to commit from master branch
lidel
changed the title
There was a problem hiding this comment.
Merging as this dependency update finally fixes problem @2color fixed in libp2p/go-libp2p-kad-dht#976
This is also unblocking us to start Kubo 0.30.0-rc1 release dance in #10436
IPNS interop tests for helia→pubsub→kubo did not execute the same tests as kubo→pubsub→helia.
Namely, publishing to IPNS was executed with assumption it will fail, as a convoluted way of confirming the kubo is not subscribed to the topic, and also kubo connectivity state is somehow taken on belief, rather than being programmatically verified:
```js
// first publish should fail because kubo isn't subscribed to key update channel
await expect(name.publish(peerId, cid)).to.eventually.be.rejected()
.with.property('message', 'PublishError.NoPeersSubscribedToTopic')
// should fail to resolve the first time as kubo was not subscribed to the pubsub channel
await expect(last(kubo.api.name.resolve(peerId, {
timeout: 100
}))).to.eventually.be.undefined()
```
Good news is that there are native APIs for inspecting subsub topic subscriptions, and this PR refactors test to use them and have tests in both directions do more-or-less the same thing with the same asserts.
This should make interop less brittle.
ipfs/kubo#10488 (comment)
https://github.com/libp2p/go-libp2p-kad-dht/releases/tag/v0.26.0cc #10436