peers ls (and possibly other broadcast commands) fail when a peer is down

[hsanjuan]

Pre-check

• This is not a IPFS Cluster website content issue (file those here)
• I read the troubleshooting section of the website and it did not help
• I searched for similar issues in the repo without luck
• All my peers are running the same cluster version
• All my peers are configured using the same cluster secret

Basic information

• Version information (mark as appropiate):
  • Master
  • Release candidate for next version
  • Latest stable version
  • An older version I should not be using
• Type (mark as appropiate):
  • Bug
  • Feature request
  • Enhancement
• Operating system (mark as appropiate):
  • Linux
  • macOS
  • Windows
  • Other: which?
• Installation method (mark as appropiate):
  • Binaries from dist.ipfs.io
  • Built from sources
  • Docker
  • Snap
  • Other: which?

Description

Pretty sure this is null-multiaddress related: https://discuss.ipfs.io/t/has-anyone-seen-this-error-cannot-unmarshal-object-into-go-struct-field/5007/4

70% sure that fix involves fixing deserialization of our types.go/Multiaddr or is somewhat related (either Undef cids or multiaddresses).

[kishansagathiya]

70% sure that fix involves fixing deserialization of our types.go/Multiaddr or is somewhat related (either Undef cids or multiaddresses).

Yup, failing during unmarshaling https://github.com/ipfs/ipfs-cluster/blob/508131081124bc8289b762ffb7e0e0572798e9be/api/rest/client/request.go#L118

[kishansagathiya]

This is happening because if a peer in down, on peer ls IPFSID is empty.

type IPFSID struct {
	ID        peer.ID     `json:"id" codec:"i,omitempty"`
	Addresses []Multiaddr `json:"addresses" codec:"a,omitempty"`
	Error     string      `json:"error" codec:"e,omitempty"`
}

If I just omitempty ID from IPFSID, thing would work with a message for the peer which is down, like

<peer.ID Qm*trvuVP> | ERROR: dial backoff

[kishansagathiya]

Resolved with #719