You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The MetricsLayer structure, which wraps an inner Filtered itself implements Layer.
The Filtered structure always returns always and let's the Registry decide on the "combined" final interest. However, in this case, while the MetricsLayer does call inner.register_callsite, the MetricsLayer itself is not a Filtered.
I believe this is a bug. I'd be happy to contribute a fix to this but I'd love to discuss how to best design this. One option is to let the users build the filtered themselves. The other is to have some sort of API that returns an actual Filtered. I'm not exactly sure if there's a way to make this work through the Layer implementation, maybe using on_layer?
Using instrument_layer.with_filter(MetricsFilter) directly fixes the issue, but both these structures are private.
The text was updated successfully, but these errors were encountered:
but I became concerned that if I wanted to add settings to MetricsLayer, I wouldn't be able to write code like MetricsLayer::new().with_foo(). So, I decided to return MetricsLayer instead.
Ideally, users could filter metrics events without being aware of it. However, if that's not possible, I thought it might be acceptable to make MetricsFilter public and use MetricsLayer::new().with_filter(MetricsFilter).
The
MetricsLayer
structure, which wraps an innerFiltered
itself implementsLayer
.The
Filtered
structure always returnsalways
and let's theRegistry
decide on the "combined" final interest. However, in this case, while theMetricsLayer
does callinner.register_callsite
, theMetricsLayer
itself is not aFiltered
.tracing-subscriber
is not able to understand thatMetricsLayer
is in fact a per-layer filter, and thisalways
is actually treated as a layer returningalways
. In turn, the registry decides to returnsometimes()
for the callsite (https://github.com/tokio-rs/tracing/blob/0e3577f6f3995b92accee21e0737c25ef0f1953c/tracing-subscriber/src/subscribe/layered.rs#L463-L472)I believe this is a bug. I'd be happy to contribute a fix to this but I'd love to discuss how to best design this. One option is to let the users build the filtered themselves. The other is to have some sort of API that returns an actual
Filtered
. I'm not exactly sure if there's a way to make this work through the Layer implementation, maybe usingon_layer
?Using
instrument_layer.with_filter(MetricsFilter)
directly fixes the issue, but both these structures are private.The text was updated successfully, but these errors were encountered: