-
Notifications
You must be signed in to change notification settings - Fork 721
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
Add special "void span" to discard all child spans #2738
Comments
You can achieve the desired effect of dropping all spans and events within a scope by setting the default subscriber to For example, you could write the following: fn map<U, F>(self, f: F) -> Secret<U>
where
F: FnOnce(T) -> U,
{
use tracing::subscriber::{self, NoSubscriber};
let _no_subscriber = subscriber::set_default(NoSubcriber::default());
Self::new(f(x))
} |
Fantastic! Thank you so much. |
Related to this - is there any way to conditionally log an |
I think I figured it out: I just created a new type and copied the Does that sound right? Is using |
I'm guessing that this is Cedar-adjacent: I think you're better off panicking if you want a construct like this. |
Why would you recommend panicking? I'd like to avoid panics, and just redact any logs from the this span, but also know that something attempted to log. |
…tion (#2883) ## Motivation Const argumetns in `level!` macros do not work when in the first position. This also seems to have fixed #2748 where literals for fields names like `info!("foo" = 2)` could not be used outside the `event!` macro. Fixes #2837 Fixes #2738 ## Solution Previsously, `level!($(args:tt))` was forwarded to `event!(target: ..., level: ..., { $(args:tt) })` but the added curly braces seem to have prevented the `event` macro from correctly understanding the arguments and it tried to pass them to `format!`. With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step. These are the two relevant `event!` blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: ``` (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => ( $crate::event!( target: $target, $lvl, { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* } ) ); (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => ( $crate::event!(target: $target, $lvl, { $($arg)+ }) ); ```
…tion (tokio-rs#2883) ## Motivation Const argumetns in `level!` macros do not work when in the first position. This also seems to have fixed tokio-rs#2748 where literals for fields names like `info!("foo" = 2)` could not be used outside the `event!` macro. Fixes tokio-rs#2837 Fixes tokio-rs#2738 ## Solution Previsously, `level!($(args:tt))` was forwarded to `event!(target: ..., level: ..., { $(args:tt) })` but the added curly braces seem to have prevented the `event` macro from correctly understanding the arguments and it tried to pass them to `format!`. With this change there may have some performance impact when expanding the macros in most cases where the braces could have been added as it will take one more step. These are the two relevant `event!` blocks I believe, the new tests used to expand to the first one (with empty fields), now they expand to the latter: ``` (target: $target:expr, $lvl:expr, { $($fields:tt)* }, $($arg:tt)+ ) => ( $crate::event!( target: $target, $lvl, { message = $crate::__macro_support::format_args!($($arg)+), $($fields)* } ) ); (target: $target:expr, $lvl:expr, $($arg:tt)+ ) => ( $crate::event!(target: $target, $lvl, { $($arg)+ }) ); ```
Feature Request
Add a special "void span" where all spans created within it are noops / removed.
Motivation
I am working on a way to ensure sensitive data is not accidentally logged by creating a wrapper type, which provides a
map()
method for users to work with the underlying secret. However, it is possible for a user to pass a function tomap()
which is instrumented with a span.I would like to be able to change it to something like
to ensure nothing is logged.
Proposal
Alternatives
There are several approaches to redacting sensitive data, but it is usually necessary to have some section of the code need to work with that data directly. It would be nice to be able to minimize the scope of where that occurs, as well as ensure that no logging happens there.
The text was updated successfully, but these errors were encountered: