`young_vclock` is set to be a unsigned int, some customers have used -1.

[angrycub]

When this is encountered in 1.4.8, This causes a non-encodeable message. Should we allow for -1 or is that a bad configuration option?

[alexmoore]

IIRC, one idea as to why they were setting it as -1 was to always have it prune if it can (instead of having to be the default of 20s old).

https://github.com/basho/riak_core/blob/develop/src/vclock.erl#L241

If they set the value to 0 it should take care of that case, unless there's the possibility of some clock skew between the time the head's time is set, and the prune command is called.

[seancribbs]

We can convert this without issue to an int32, but sending -1 will probably cause a crash on older nodes/clients.

[angrycub]

So the issue arose when a customer began moving to 1.4.x from 1.1.1 and things started blowing up just for context

[seancribbs]

@angrycub Sure, understood. We didn't have fullbokat properties until 1.4.

[seancribbs]

For reference, here's what happens when we go each direction between int32 and uint32:

%% int32 -> uint32
2> V = protobuffs:encode(1, -1, int32).
["\b",[255,255,255,255,255,255,255,255,255,1]]
3> V1 = iolist_to_binary(V).
<<8,255,255,255,255,255,255,255,255,255,1>>
4> protobuffs:decode(V1, uint32).
{{1,18446744073709551615},<<>>}
%% uint32 -> int32
6> U = iolist_to_binary(protobuffs:encode(1, 1, uint32)).
<<8,1>>
7> protobuffs:decode(U, int32).
{{1,1},<<>>}