-
Notifications
You must be signed in to change notification settings - Fork 731
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter leak when using WithSubscriber #902
Comments
I think I know what's up here. When a tracing/tracing-core/src/dispatcher.rs Line 409 in 7f24283
This stores cached filter evaluations from all current subscribers in the per-callsite cache. However, when a I think we ought to change this so that whenever the last clone of a |
@jeromegn the fix I described above should be fairly straightforward to implement, if you're interested in getting another |
I can give it a shot! Will probably ask for help on Discord though :) |
…bers (#927) ## Motivation Currently, when multiple subscribers are in use, the way that `Interest` values are combined results in surprising behavior. If _any_ subscriber returns `Interest::always` for a callsite, that interest currently takes priority over any other `Interest`s. This means that if two threads have separate subscribers, one of which enables a callsite `always`, and the other `never`, _both_ subscribers will always record that callsite, without the option to disable it. This is not quite right. Instead, we should check whether the current subscriber will enable that callsite in this case. This issue is described in #902. ## Solution This branch changes the rules for combining `Interest`s so that `always` is only returned if _both_ `Interest`s are `always`. If only _one_ is `always`, the combined interest is now `sometimes`, instead. This means that when multiple subscribers exist, `enabled` will always be called on the _current_ subscriber, except when _all_ subscribers have indicated that they are `always` or `never` interested in a callsite. I've added tests that reproduce the issues with leaky filters. Fixing this revealed an additional issue where `tracing-subscriber`'s `EnvFilter` assumes that `enabled` is only called for events, and never for spans, because it always returns either `always` or `never` from `register_callsite` for spans. Therefore, the dynamic span matching directives that might enable a span were never checked in `enabled`. However, under the new interest-combining rules, `enabled` *may* still be called even if a subscriber returns an `always` or `never` interest, if *another* subscriber exists that returned an incompatible interest. This PR fixes that, as well. Depends on #919 This was previously approved by @yaahc as PR #920, but I accidentally merged it into #919 _after_ that branch merged, rather than into master (my bad!). Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Confirmed fixed by 2a5da8d |
Bug Report
Version
Platform
Linux 5.7.12-arch1-1
Crates
tracing-subscriber (probably)
Description
When using the
WithSubscriber
trait, the filter appears to leak to the global subscriber. At least when not setting any filter.I'm using a global subscriber with an
EnvFilter
. If I use something like:then once my future completes, my global subscriber has "changed" (I think) and no longer filter events or spans according to the original setting. In my use case I was setting the level to "info" and I started getting events and spans with traces up to the "trace" level.
The text was updated successfully, but these errors were encountered: