This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
ipfs-http-client dht functions throw exceptions too early #2991
Comments
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
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.
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 atype: 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 atype: 3
message. The example code below more often than not fails to discover any providers at all, with error messages such asError: dial backoff
orError: failed to dial : all dials failed
orError: 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.
The text was updated successfully, but these errors were encountered: