tracing_subscriber::fmt::init() inconsistencies with transient env-filter flag

[kykosic]

Bug Report

Version

binary-crate v0.1.0 (../tracing-init/binary-crate)
├── tracing v0.1.41
│   ├── tracing-attributes v0.1.30 (proc-macro)
│   └── tracing-core v0.1.34
└── tracing-subscriber v0.3.19
    ├── tracing v0.1.41 (*)
    ├── tracing-core v0.1.34 (*)
    └── tracing-log v0.2.0
        └── tracing-core v0.1.34 (*)
lib-crate v0.1.0 (../tracing-init/lib-crate)
└── tracing-subscriber v0.3.19 (*)

Platform

N/A

Crates

tracing-subscriber

Description

See this repository interactive for reproduction: https://github.com/kykosic/tracing-init

Following previous discussions about inconsistent init behavior (#735, #1329, #2217, #2514), the additional unexpected behavior I'd like to add is that the tracing_subscriber::fmt::init() function behavior can change by simply adding a dependency on a 3rd crate, which may enable the env-filter feature of tracing-subscriber transiently.

In the above linked repo, I test the following block of code given different init methods:

    tracing::debug!("debug message!");
    tracing::info!("info message!");
    tracing::error!("error message!");

If you initialize with tracing_subscriber::fmt::init(), everything works as expected:

$ cargo run --features init-function
2025-06-30T19:54:28.027555Z  INFO binary_crate: info message!
2025-06-30T19:54:28.027675Z ERROR binary_crate: error message!

$ RUST_LOG=debug cargo run --features init-function
2025-06-30T19:54:33.248545Z DEBUG binary_crate: debug message!
2025-06-30T19:54:33.248623Z  INFO binary_crate: info message!
2025-06-30T19:54:33.248637Z ERROR binary_crate: error message!

However, if you add a dependency on some arbitrary crate that also depends on tracing-subscriber but enables the env-filter feature, then suddenly with no real changes to your code the logging changes to ERROR by default:

$ cargo run --features init-function,transient-env-filter
2025-06-30T19:57:07.640891Z ERROR binary_crate: error message!

$ RUST_LOG=debug cargo run --features init-function,transient-env-filter
2025-06-30T19:57:14.889001Z DEBUG binary_crate: debug message!
2025-06-30T19:57:14.889113Z  INFO binary_crate: info message!
2025-06-30T19:57:14.889121Z ERROR binary_crate: error message!

I want to add this evidence to existing issues as they all demonstrate poor user experience with tracing_subscriber::fmt::init() (and possibly that tracing_subscriber::fmt().init() ought to be consistent too). Possible solutions to these issues:

• This function is made consistent regardless of feature flags.
• An alternative function is introduced that does have consistent behavior.
• Any combination of the above that results in better 1-liner initialization for the most common use cases, and less confusion with tracing_subscriber::fmt().init().