-
Notifications
You must be signed in to change notification settings - Fork 720
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
tracing-subscriber: inconsistent behavior between init
methods
#2217
Comments
This issue is a duplicate of #1329, but you're right about the discrepancy. Would you be willing to submit a PR to the v0.1.0 branch fixing the incorrect documentation on |
Is the correct thing to do here to change the comment to reflect that they are not the same or to fix the code so that they are the same? I can see the argument for changing just the documentation since somebody might already rely on this functionality and 0.2 does not have this problem. |
At the moment, we should just change the documentation to reflect reality. The right solution might require a bit more thought. |
Previously the documentation for `fmt::init()` was misleading. It stated that it was shorthand for `fmt().init()`. This lead to confusion as users would expect the same behavior from both. However `fmt::init()` would, whether you used the env-filter feature or not, rely on RUST_LOG to set the tracing level. `fmt().init()` does not do this and it must be set with a specific configuration via `with_env_filter`. The documentation has been updated to no longer state that it is 1:1 shorthand for the other. The documentation now specifically points out that you must be using the `env-filter` feature and gives a correct example to mimic the `fmt::init()` behavior using `fmt().init()`. fixes: tokio-rs#2217 tokio-rs#1329
## Motivation Previously the documentation for `fmt::init()` was misleading. It stated that it was shorthand for `fmt().init()`. This lead to confusion as users would expect the same behavior from both. However `fmt::init()` would, whether you used the env-filter feature or not, rely on RUST_LOG to set the tracing level. `fmt().init()` does not do this and it must be set with a specific configuration via `with_env_filter`. ## Solution The documentation has been updated to no longer state that it is 1:1 shorthand for the other. The documentation now specifically points out that you must be using the `env-filter` feature and gives a correct example to mimic the `fmt::init()` behavior using `fmt().init()`. Fixes #2217 Fixes #1329 Co-authored-by: Eliza Weisman <[email protected]>
## Motivation Previously the documentation for `fmt::init()` was misleading. It stated that it was shorthand for `fmt().init()`. This lead to confusion as users would expect the same behavior from both. However `fmt::init()` would, whether you used the env-filter feature or not, rely on RUST_LOG to set the tracing level. `fmt().init()` does not do this and it must be set with a specific configuration via `with_env_filter`. ## Solution The documentation has been updated to no longer state that it is 1:1 shorthand for the other. The documentation now specifically points out that you must be using the `env-filter` feature and gives a correct example to mimic the `fmt::init()` behavior using `fmt().init()`. Fixes tokio-rs#2217 Fixes tokio-rs#1329 Co-authored-by: Eliza Weisman <[email protected]>
Bug Report
Version
tracing-subscriber v0.3.14
tracing v0.1.35
Platform
x86_64-unknown-linux-gnu
Crates
tracing-subscriber
Description
There appears to be a discrepancy in what the documentation believes is true and what the different format initializers actually do.
tracing_subscriber::fmt::init()
has documentation saying it is the same astracing_subscriber::fmt().init()
. I think there may be two bugs.builder.with_max_level(LevelFilter::TRACE)
instead of usingDEFAULT_MAX_LEVEL
which is set toINFO
.tracing_subscriber::fmt().init()
does NOT use env filters andtracing_subscriber::fmt::init()
does. This leads to confusing behavior when switching between implementations that are supposed to be the same. NOTE, as far as I can tell this is fixed in main branch.Example
To reproduce bug 2:
using
fmt::init()
using
fmt().init()
The text was updated successfully, but these errors were encountered: