Cid.Undef IPLD de-serialization error

[adlrocha]

If we use cid.Undef to create a new datamodel.Link with cidLink, it is serialized as "/": "b", which means that when trying to de-serialize it, we get cid is too short. I don't think we should error in this case. We should probably not serialize cid.Undef, or use a Null type, to allow de-serialization in the other end. I don't know if this the expected behavior we wanted for cid.Undef or it is open to discussion.

Background

I was serializing an IPLD node map with a bunch of links, some of them were cid.Undef, and I was getting cid is too short. I was blaming the Links which were actually set, when in the end it was the cid.Undef the one to blame.

[rvagg]

🤯

Undef can be used to represent a nil or undefined Cid

so yeah, this should probably be interpreted as Absent somehow, and then error if the schema doesn't allow for it in that place. Maybe if there's a union that allows for Null in that position it might make sense, but that seems like a stretch.

OR, just error earlier, or with a more informative message to discourage use of Undef or better checking upstream.

[willscott]

Note that part of this duality is because of the quirk in how we represent Cid's in Golang. Since they are strings, a primitive type, they cannot be 'nil', and so Undef gets commonly used for that 'not yet set' case that may represent either explicit Absentness or Null

[rvagg]

#196 possibly helps with this?

[rvagg]

Revisiting this, I think maybe our codecs need to special-case this and convert to Null, like we're currently doing for Absent; needs a PR to propose and test that approach. Assigning myself.