[v20.07.0-beta.Jun22] time.UnmarshalBinary: unsupported version

Users Dgraph
1

Due to the new facet design, we were stuck at v1.1.1 until the release of the current beta. I am not sure why the liveness and readiness probes are disabled by default in the Helm charts, but that is not my main issue at the moment.

When committing a mutation, I get the error returned: time.UnmarshalBinary: unsupported version. In an earlier version, I resolved this to a date to be stored as a string, but committed as a datetime.

However, in this case, the schema has all time-like predicates set to datetime and the client also submits datetime values like such:

&api.Facet{
    Key:     "scheduled_at",
    Value:   []byte(time.Now().Format(time.RFC3339)),
    ValType: api.Facet_DATETIME,
},

Let me know what other information is needed to get a better understanding.

2

Is there a short script or description of the events that lead you to reproduce this issue. I think I can guess some of them but I want to be sure.

In the meantime, I searched for the error and the error is being thrown by the time standard library, not by Dgraph.

This is the code in question:

	if buf[0] != timeBinaryVersion {
		return errors.New("Time.UnmarshalBinary: unsupported version")
	}

timeBinaryVersion is a constant set to 1. So this function expects the first byte to be 1. I think the problem is that UnmarshalBinary does not expect a byte containing the string representation of a date. It expects a byte slice in the format outputted by time - The Go Programming Language.

so the code should be:

binaryTime, err := time.Now().MarshalBinary()
....

&api.Facet{
    Key:     "scheduled_at",
    Value:   binaryTime,
    ValType: api.Facet_DATETIME,
},
2 Likes
3

Hi Martin, thank you for your quick reply.

It seems like the logical explanation.
I will implement this tomorrow morning and let you know in this thread.
It is odd that this worked fine earlier; perhaps the time module changed between the old version and the current one?

4

@martinmr, just letting you know that your approach works as intended. I did also check that in our instances where we are still using v1.1.1, we use the method as described in my initial post without issues. Perhaps someone else in the future might benefit from this :). Thank you for helping!