Make id zero reserved as no ID

[codefromthecrypt]

Over a while, a few people have expressed interest in making span ID zero invalid. This mostly has impact to semantics of no ID and span id generators:

No ID applied to Zipkin:

• In zipkin parent id being absent means it is the root span, ex you leave the field out of json (or set it to null) vs setting it to 0
• In finagle's fixed-width encoding, there was a special comparison of when span id == trace id == parent id, it is the root span. This is interesting because it doesn't require interpreting the value ids, rather comparing them

Here are some reasons to make zero special:

• In some languages zero means false, so dodging ID zero can avoid some confusion when people write custom zipkin code.
• in fixed-width binary encoding, you cannot represent null without a flag. If zero implies no ID, you don't need a flag.
• In memory, the parent id is bigger since we need a reference to indicate if it is null or not. If zero meant unset, we don't need to box the u64.

Here is the work needed if we make zero special:

• we'd coerce zero to null where we accept span IDs
• all instrumentation need to avoid generating zero (ex while (id == 0) id = randomId )
• we have to be explicit that by zero we really mean no bits :) numeric interpretation of IDs has led to confusion before, especially encoding.

Thoughts? cc @openzipkin/instrumentation-owners @mansu @bogdandrutu @openzipkin/core

[mansu]

I think one consequence of this change is that the span and trace ids will be numeric id now. To simplify the logic further, does it make sense to make the span id and trace id be positive numbers?

[codefromthecrypt]

I think one consequence of this change is that the span and trace ids will be numeric id now. To simplify the logic further, why not make the span id and trace id be positive numbers?

Using this to escalate into numeric interpretation of IDs is the opposite of my intent. I don't want people ordering them or trying to encode them as numbers etc. We've been there before and that's exactly why we use hex in json and headers. The only reason we use longs is to get a fixed width buffer of 64bits. So what this proposes is that regardless of if you are using a uint64 or a string of hex characters to hold span ids, if all bits are unset, it is the same as null. note I don't actually like this.. just raising the issue so that when the next person asks, there's a place to hold the discussion.

[basvanbeek]

It will mess up statistical distribution of a lot of Samplers which expect 0 to be a valid position. Not sure if this is of importance for people but yet another side effect.

I'm not a huge fan of this idea.