subscriber: add new_span, on_enter, on_exit, and on_close hooks to Filter

[hawkw]

Feature Request

Crates

• tracing-subscriber

Motivation

Currently, if a Filter is going to implement dynamic filtering, it must do this by querying the wrapped Subscriber for the current span context. Since Filter only has callsite_enabled and enabled methods, a Filter implementation cannot track the span context internally, the way a Layer can.

Unfortunately, this means that the current implementation of EnvFilter can only implement Layer (and provide global filtering). It cannot currently implement Filter, because it stores span context data internally. See #1868 for details.

Proposal

We should add on_new_span, on_enter, on_exit, and on_close methods to Filter. This would allow implementing Filters (such as EnvFilter) that internally track span states.

Alternatives

There are essentially two other options for implementing Filter for EnvFilter:

• We could rewrite the implementation to use the LookupSpan APIs to store span data in the registry, and query that instead of internally. This might potentially require a breaking change, as EnvFilter would require the Subscriber to implement LookupSpan.

  Another hurdle is that the way EnvFilter is currently implemented also requires a new_span notification. Currently, the Filter trait cannot store data for a span when that span is created, even if that data is used for filtering later. This is because it only receives enabled method calls when spans are created. It cannot store data in the span for filtering events, because the span has not yet been created yet. Potentially, if we prefer to make a smaller, more targeted modification to the Filter trait, we could just add a new_span method.

• Or, we could use an approach where the EnvFilter is shared between a struct implementing Filter and a struct implementing Layer, where the Layer does not perform any actual filtering, but simply mutates the shared EnvFilter's span state. I discussed that in EnvFilter does not implement Filter #1868 (comment). This would allow a Filter impl for EnvFilter without modifying the Filter trait, but it seems quite gross and makes the API worse.