Avoiding infinite trace/log generation.

[lalitb]

Any suggestion on avoiding the infinite loop generation scenario where the custom tracing subscriber/layer uses the dependencies that are tracing themself? So in OpenTelemetry scenario, top level tracing span ->tracing-opentelemetry -> otlp exporter -> tonic -> tonic dependencies starting tracing spans and so it recurses that way and hangs. The requirement would be to filter only the traces generated from within the subscriber (and it's dependencies), and not for the usage of these dependencies from application itself.
So

application -> crate-X -> span shouldn't be dropped/filtered

application -> tracing-opentelemetry -> otlp-exporter -> tonic -> crate-X -> span should be dropped/filtered.

Related issue - open-telemetry/opentelemetry-rust#761
Some of the options discussed - open-telemetry/opentelemetry-rust#761 (comment)

[mladedav]

For simple scenarios tracing-tree detects recursive tracing calls via thread-local storage.

But from skimming over the issue you linked, there is a more complex interaction going on, where opentelemetry-sdk sends spans to a previously spawned task which itself could also spawn other tasks, right?

When you're spawning the task you might use with_subscriber(NoneSubscriber) (maybe I'm misremembering the name of the subscriber) which should work for the task but then inside the subscriber would also have to be added to child tasks with with_current_subscriber().