bug: KuboClient not returning multiaddrs in FIND_PEER event

[p-shahi]

          @p-shahi I tried upgrading to the latest but now I get this error. Seemingly finding the peer no longer works

swarm connecting the peer does work

Originally posted by @TheGreatAlgo in #1951 (comment)

UPDATE

the JS RPC Kubo client is currently is returning a successful FIND_PEER event despite not having any diall-able addresses, which leads the delegated-peer-routing findPeer method to throw a ERR_NOT_FOUND

Blocked by ipfs/js-kubo-rpc-client#176

[p-shahi]

@maschad mind investigating this?

[AustinFoss]

I'm not sure this is a problem anymore. I remember having this same thing a few weeks (maybe a little over a month ago and thought it was something about the kadDHT's client mode not working properly. I now can successfully call findPeer() from a browser node with:

      dht: kadDHT({
          clientMode: true
      })

libp2p version 0.46.6

[maschad]

Thanks for that feedback @AustinFoss but the description may have been a bit misleading, this issue actually is within the context of using delegated-peer-routing which relies on the JS RPC Kubo client to find peer's on a node's behalf. I've updated the description to reflect this.

For more details you can see ipfs/js-kubo-rpc-client#176

[SgtPooki]

related to ipfs/kubo#10117

[p-shahi]

Are we reliant on the new Kubo RC to resolve this issue?

[aschmahmann]

AFAICT the issue here isn't that some functionality is bugged in kubo that's preventing js-libp2p from dialing peers just that kubo was returning effectively "yes I found the peer ... oh but no addresses" rather than "no I didn't find the peer".

You can be defensive in js-kubo-rpc-client or js-libp2p-delegated-peer-routing to turn a no address response into an error.

I suspect the user that filed this bug wants kubo to return their peer's address and let them dial it in js-libp2p though, and if that's not happening then something else is going wrong (e.g. the target node isn't a DHT client, etc.).

[maschad]

You can be defensive in js-kubo-rpc-client or js-libp2p-delegated-peer-routing to turn a no address response into an error.

So that's currently the case in delegated peer routing which js-libp2p was propagating here as the NOT_FOUND error.

I suspect the user that filed this bug wants kubo to return their peer's address and let them dial it in js-libp2p though, and if that's not happening then something else is going wrong (e.g. the target node isn't a DHT client, etc.).

Yup you are spot on, it was the DHT client being disabled, thanks @aschmahmann

[p-shahi]

@maschad I saw you closed this issue - I know you had a local setup to reproduce the original issue - were you able to apply @AustinFoss 's suggestion and get it working?

[maschad]

@maschad I saw you closed this issue - I know you had a local setup to reproduce the original issue - were you able to apply @AustinFoss 's suggestion and get it working?

That's correct, once clientMode was enabled I was able to retrieve the peerInfo via the findPeer method, you can see the example here

[p-shahi]

Cool

Thanks for the explanation as well @aschmahmann 🙏