Right now, we document "spanId" as what insures mechanisms such as TTL or gaps. This also solves a secondary problem, which is knowing if the sampling key was ever sampled before (ex same as b3 sampled=1). An alternative would be to add another field, or delimited property, to indicate the sampling status of the key. However, this would increase the parsing complexity and the overhead of the header.
I didn't mention aloud, but "spanId" serves the same purpose. The rationale summarizes as
things will break if you don't know the upstream span ID. Instead of adding a separate sampled parameter, which may lead to people not adding spanId and then breaking traces, we leverage "spanId" instead.
Note: we don't yet have a RATIONALE.md so this may imply creating it.
Right now, we document "spanId" as what insures mechanisms such as TTL or gaps. This also solves a secondary problem, which is knowing if the sampling key was ever sampled before (ex same as b3 sampled=1). An alternative would be to add another field, or delimited property, to indicate the sampling status of the key. However, this would increase the parsing complexity and the overhead of the header.
I didn't mention aloud, but "spanId" serves the same purpose. The rationale summarizes as
Note: we don't yet have a RATIONALE.md so this may imply creating it.