Allow ending/deleting/destroying a span without having it be recorded

[Falmarri]

I have a somewhat annoying situation in my code that's kind of hard to explain, so I won't exactly go into it unless it's necessary. But the short story is sometimes I create a span, but later realize that the span isn't actually relevant to my workflow and I want to abandon it without recording it. The reason for this is that the system can create hundreds of thousands of spans, but only a small portion are relevant, and it's very hard for me to know beforehand whether it will be relevant or not.

I realize this is far from ideal, but I'm working in the bounds of an existing 3rd party library that my code is running as an extension of, so I don't have much of an option to change. I can probably come up with a workaround, but my first thought was just to create the spans always, but only record them after knowing they interact with my flow. Maybe there could be a span->Abandon() method or something like that?

[lalitb]

Please note

• There is no method at API surface to destroy/abandon the Span. Span once created need to end either explicitly by calling Span::End(), or automatically when it's destructor gets called.
• At SDK level ,you can implement Sampler which make sampling/recording decision upfront when Span is started.

So, once Span is created, and not sampled by Sampler, it would get ended and eventfully exported. One of the option is to create a custom span-processor which implements tail-based sampling. And for this to work, you also need a custom exporter which implements the Recordale::SpanData() method. Or else, your custom exporter can do the filtering too. There have been some discussions in #2108.

[lalitb]

@Falmarri do you have more queries, or can we close this issue ?

[ThomsonTan]

For the potential API Span::Abandon, probably raise it to the API specification repo? But it has some edge cases like whether the child spans need to be discarded as well.

[marcalff]

Closing, this feature is not supported by opentelemetry in general.

Instead of creating a span and later "abandon" it, also consider to delay the span creation until the application can decide if it it needed or not.

[Falmarri]

Instead of creating a span and later "abandon" it, also consider to delay the span creation until the application can decide if it it needed or not.

This is what I ended up doing, though it's not ideal because the next span could be one of several. And so there are a few places I have to lazily create the parent span. But it works.