Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

ipfs-http-client dht functions throw exceptions too early #2991

Closed
phillmac opened this issue Apr 19, 2020 · 1 comment · Fixed by #3001
Closed

ipfs-http-client dht functions throw exceptions too early #2991

phillmac opened this issue Apr 19, 2020 · 1 comment · Fixed by #3001

Comments

@phillmac
Copy link
Contributor

Ping @alanshaw

  • Package: ipfs-http-client

  • Version: >41.0.0

Type: Bug

Severity: High

Description:

Calls to DHT functions e.g. findProvs() fail too quickly on encountering a type: 3 message from the ipfs node. This seems to be naive, as type 3 error messages are not fatal to the dht functions; very often a valid response is obtained after a type: 3 message. The example code below more often than not fails to discover any providers at all, with error messages such as Error: dial backoff or Error: failed to dial : all dials failed or Error: failed to dial : no good addresses. These are to be expected and should not abort the operation.
The effect is that the dht functions are rendered unusable because of the highly erratic nature of the errors and the unreliability of getting any results.

This change was implemented in version 41.0.1,
PR: ipfs-inactive/js-ipfs-http-client#1183

Steps to reproduce the error:

Code e.g.

const IPFS = require('ipfs-http-client')
const hashes = [
  "zdpuAuSAkDDRm9KTciShAcph2epSZsNmfPeLQmxw6b5mdLmq5",
  "zdpuAmm8YdN9eHmQ2WHNShrdLF58SYEsqzDRFsx5GrCDVmNLr",
  "zdpuAwo4v8f1NYbUpoPSmCCondF2UPeB7fEqmWPQZD9Ss9Kts",
  "zdpuAyJcWDGajL3XMJf5iRmMRwM1zwAp3u2d928gZgr3ED8EB",
  "zdpuAyx3MUm6ZtkvabuMqbBZpnoPqsnAhnDpcCPYj9tBCmXff"
]

const ipfs = IPFS()

async function findProvs(hash) {
  const providerList = []
  const find = ipfs.dht.findProvs(hash)  
  try {
    for await (const provider of find) {
      providerList.push(provider)
      console.log(provider)
    }
  } catch (err) {
    console.error(err)
  }
  return providerList
}

hashes.forEach(async function (h) {
  console.log(h, await findProvs(h))
})

achingbrain added a commit that referenced this issue Apr 24, 2020
Response streams from DHT operations contain lots of message types, one
of which is 'Error', but they are emitted for all sorts of reasons, failing
to dial peers, etc and valid responses can arrive after several errors.

The change here is to ignore error messages sent by the remote node as
they do not indicate that the request has failed.

It also makes the response types consistent in that previously we only
turned some peer IDs into CIDs, now they are all CIDs all the time.

Fixes #2991
@achingbrain
Copy link
Member

@phillmac this should be resolved by #3001 - could you take a look at the changes on that PR and comment if anything’s been missed?

achingbrain added a commit that referenced this issue Apr 27, 2020
Response streams from DHT operations contain lots of message types, one of which is 'Error', but they are emitted for all sorts of reasons, failing to dial peers, etc and valid responses can arrive after several errors.

The change here is to ignore error messages sent by the remote node as they do not indicate that the request has failed.

Fixes #2991
SgtPooki referenced this issue in ipfs/js-kubo-rpc-client Aug 18, 2022
Response streams from DHT operations contain lots of message types, one of which is 'Error', but they are emitted for all sorts of reasons, failing to dial peers, etc and valid responses can arrive after several errors.

The change here is to ignore error messages sent by the remote node as they do not indicate that the request has failed.

Fixes #2991
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 a pull request may close this issue.

2 participants