tokio-rs / tracing

Application level tracing for Rust.
https://tracing.rs
MIT License
5.19k stars 677 forks source link

allow span_scope to iterate from a filtered current_span #2898

Closed xuorig closed 4 months ago

xuorig commented 4 months ago

Note: opening this PR not as a full solution but rather to talk about the use case / discuss if this makes sense.

I'm working on a layer that uses a per-layer filter. This layer very carefully selects a single span callsite to extract some of its attributes and store them in extensions. This same layer then uses extensions previously set to format events with some contextual elements.

The problem is that this span callsite, let's call it A, is not necessarily the event's current span:

a {
  b {
    c {
       event!
    }
  }
}

If other layers are enabled for b and c, when we get to event!, the current_span is c. However, with PLF, the call to ctx.span(current_id) will return None since our filter does not enable the c span.

When the current_span is visible by the filter, span_scope's iterator actually handles these cases well. It seems to simply continue to the next parent until it finds spans that the filter can see. However, when the current_span is not visible, we don't get to iterate on any of the scope.

What I'm trying to achieve might be weird in the first place, but I do wonder if scope functions should let the iterator filter out spans, even the current one, instead of short circuiting right away. In this PR, this is achieved by using self.subscriber.as_ref()?.span(id)?; instead of going through Context#span which implements the filtering.

Of course this would change the contract of this function / other scoping functions, so this is mainly to show the problem. Would be happy to provide another tool to achieve this if needed. Thanks!

xuorig commented 4 months ago

After implementing basically exactly what lookup_current_filtered does... I just realized that's exactly what ctx.lookup_current is for 🤦‍♂️. Closing.