census-instrumentation
Make root span trace IDs unique
This PR fixes a longstanding bug: that all spans generated by a given ContextTracer share the same trace ID regardless of the context. This meant sequential root spans were reported as siblings in the same trace instead of each belonging to its own trace.
Fixes #182 and #366. See https://github.com/census-instrumentation/opencensus-python/issues/182#issuecomment-461647639 for more detail.
cc @tab1293, @sduskis.
I'll mention here too that this PR does not fix #182 for me while my proposed change #539 does.
what's the story with this PR?
I hadn't merged it because it was breaking a system test that was asserting the wrong behavior. Still TODO.
this PR does not fix #182 for me while my proposed change #539 does
This PR deals with siblings spans having the same trace ID when the parent trace ID is null, #539 changes the grpc client interceptor so that it uses the current tracer to set trace IDs instead of the tracer that was current at the time the interceptor was created. Both problems affect the google-cloud-python integration, and both cause clashing traceIDs, but each has a different root cause.
@nikhaldi does that match your understanding?
I see what you mean, thanks. I don't have enough background about how people use the API to judge if the case of a null parent trace id is valid. My reading of the code tracking down my issues was that the API requires a new tracer to be created for every individual trace. But if that's not case this PR seems reasonable.