Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Where could we (in principle at least) allow users to control span creation #180
meta topic: Until there's a different issue on the topic, I'd keep discussion there. For example, there's only one use case pattern requested. Jumping between issues loses context and makes having the discussion less relevant unless the actual use case is copy-pasted into the description (which makes it look like the first issue again).
I think the topic, especially relating to the issue, has two parts:
Our tracer api conflates propagation with span creation
The Tracer api has a wrap method which in default form implies eagerly creating a new span. There's a question about this api in general, which is fair as the behavior isn't usual. For example, it seems Finagle, Brave, and HTrace at least don't conflate these things. Most tracer apis concern themselves with propagating context divorced from starting a span. Why do we believe our tracer api should conflate these?
If this can be changed, it would be easier to make custom instrumentation that doesn't create "junk" spans. Regardless, this is so unusual, it should be documented.
For example, TraceCallable says "Callable that passes Span between threads." That's a normal statement, but the actual code eagerly creates a span on run (which is the abnormal part). Such a behavior should be very obvious in docs if we believe our api is correct.
Should our implicit instrumentation eagerly create spans?
This is a different topic, but if depends on the above. For example, if we didn't make eager spans, then we'd likely not get the issue in the first place. I think it is best to address the root api concern before auditing each instrumentation and seeing if it should have an "eager" setting or not.