Trace id in link is invalid! (Links)

[zeroflaw]

I'm constantly getting the following error "Trace id in link is invalid!"

I'm including a link of type parent with the correct TraceID and SpanID (parent) with link type Parent.
and I always get the same error message. No matter what I do.

I don't need to include this link because if I set SpanData.ParentSpanID everything links up correctly. However, I would like to understand why I'm getting the above error. I'm logging the output of the traceIds so I know they are identical. What makes a TraceID invalid?

link traceid: "[59 76 239 104 169 158 19 60 252 132 156 231 91 52 133 0]"
traceid: "[59 76 239 104 169 158 19 60 252 132 156 231 91 52 133 0]"

[semistrict]

Hi @zeroflaw thanks for reporting this. Could you tell us what Exporter you are using?

[zeroflaw]

I'm using the stackdriver exporter

[semistrict]

Not sure if it is the issue but it looks like the linked TraceID and the TraceID you provided are identical. Are you always using identical TraceID and linked TraceID?
Are you explicitly creating Links or is this happening just because you're using ochttp or ocgrpc which create links under the hood sometimes?
If you are, what are you using linked spans to represent?

[zeroflaw]

I am mapping the opencensus.SpanData myself. The simplest way to replicate this error is:

var tid [16]byte
var sid [8]byte
var pid [8]byte

spanData := &trace.SpanData{
		SpanContext:     trace.SpanContext{TraceID: tid, SpanID: sid, TraceOptions: trace.TraceOptions(1)},
		ParentSpanID:    pid,
		Name:            name,
		StartTime:       startTime,
		EndTime:         endTime,
		Links:          trace.Link{ TraceID:    tid, SpanID: pid,  Type: trace.LinkTypeParent, Attributes: nil},
	}

I then call the Exporter(spanData)

I'm using the ParentSpanID in the link for SpanID. If I don't include the link everything works. If I add a link, I always get the same error. (I've even tried not including the TraceID and I get the same errror.

I hope this information is useful.

[semistrict]

I'm not sure what the error is, I will need to investigate a little more. But you shouldn't need to add a Link to the normal parent span in the current trace. I believe that links are meant to reference other traces (with different TraceID).

Also just a heads up, we were not planning on stabilizing the Exporter API because we didn't intend for end-users to use this directly for now. Could you tell us a little more about why you are directly using the exporter rather than the trace package?

[zeroflaw]

Ahh right, I guess that makes sense, but i'm not sure why including the same TraceID should cause the entire export to fail. At the very minimum please consider replacing 'Invalid' in the error with 'TraceID can not be same as parent span TraceID'.

My reason for using the Exporter API directly is I have packages dependant on
Opentracing ---> Jaeger Tracing

which I would previously export to Stackdriver using:
Jaeger Tracing Zipkin Transport ---> Zipkin-GCP collector

For multiple reasons I just wanted to export Jaeger Tracing (Opentracing), directly to Stackdriver. Which means I'm able to support MessageEvent and Annotations, and link remote parents better. Its simply at lot better than the Zipkin-GCP collector and it only took me a couple of hours to map SpanData as its a very simple conversion. (part from span.Refs ---> span.Links, which confused me.)

Opentracing ---> Jaeger Tracing ---> Opencensus ---> Stackdriver

Lots of packages already use Opentracing, so having the above flow makes sense. I guess this would also be possible for any packages dependant on Opencensus (such as the oc plugins).
Opencensus ---> Opentracing ---> Jaeger Tracing ---> Opencensus ---> Stackdriver

[rakyll]

I filed an issue internally to improve the error message.

[semistrict]

I don't believe that this issue is caused by using the same TraceID in the link as the span. I managed to reproduce it with an arbitrary link: #692

Needs more investigation but seems like right now we cannot upload any linked spans to Stackdriver.

[rakyll]

I have a fix for this, will send out soon.

[zeroflaw]

I did a test and it worked for me 👍