Skip to content
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

Open
cgbur opened this issue Jul 12, 2022 · 3 comments
Open

tracing-subscriber: inconsistent behavior between init methods #2217

cgbur opened this issue Jul 12, 2022 · 3 comments

Comments

@cgbur
Copy link
Contributor

cgbur commented Jul 12, 2022

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 as tracing_subscriber::fmt().init(). I think there may be two bugs.

  1. That code eventually calls builder.with_max_level(LevelFilter::TRACE) instead of using DEFAULT_MAX_LEVEL which is set to INFO.
  2. tracing_subscriber::fmt().init() does NOT use env filters and tracing_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:

# cargo.toml

[package]
name = "tracing-test"
version = "0.1.0"
edition = "2021"

[dependencies]
tracing-subscriber = "0.3"
tracing = "0.1"

using fmt::init()

fn main() {
    tracing_subscriber::fmt::init();

    tracing::error!("error");
    tracing::warn!("warn");
    tracing::info!("info");
    tracing::debug!("debug");
    tracing::trace!("trace");
}
❯ RUST_LOG=TRACE cargo run --
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/tracing-test`
2022-07-12T17:37:31.613776Z ERROR tracing_test: error
2022-07-12T17:37:31.613807Z  WARN tracing_test: warn
2022-07-12T17:37:31.613820Z  INFO tracing_test: info
2022-07-12T17:37:31.613832Z DEBUG tracing_test: debug
2022-07-12T17:37:31.613843Z TRACE tracing_test: trace

using fmt().init()

fn main() {
    tracing_subscriber::fmt().init();

    tracing::error!("error");
    tracing::warn!("warn");
    tracing::info!("info");
    tracing::debug!("debug");
    tracing::trace!("trace");
}
❯ RUST_LOG=TRACE cargo run --
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/tracing-test`
2022-07-12T17:38:33.822023Z ERROR tracing_test: error
2022-07-12T17:38:33.822055Z  WARN tracing_test: warn
2022-07-12T17:38:33.822067Z  INFO tracing_test: info
@davidbarsky
Copy link
Member

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 tracing_subscriber::fmt().init()?

@cgbur
Copy link
Contributor Author

cgbur commented Jul 13, 2022

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.

@davidbarsky
Copy link
Member

At the moment, we should just change the documentation to reflect reality. The right solution might require a bit more thought.

cgbur added a commit to cgbur/tracing that referenced this issue Jul 16, 2022
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
hawkw added a commit that referenced this issue Jul 28, 2022
## 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 <eliza@buoyant.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants