-
Notifications
You must be signed in to change notification settings - Fork 56
Bug: color_eyre
interference with tracing
in some cases
#110
Comments
wow, that's uuuh, interesting... I'll look into what's causing that. For now is installing the subscriber first possible? I'm just trying to get a sense of this issue's urgency. |
I switched to It's not that urgent, but we can't move the initialization of |
This still happens with color-eyre 0.6.2 and tracing-subscriber 0.3.16 / tracing-core 0.1.30. I tried looking into why this is happening, and the short version is that creation of an https://github.com/yaahc/color-eyre/blob/v0.6.2/src/config.rs#L1047 which in turns creates a and stores that no-op subscriber as the current thread dispatcher, which has a Later when the info event is logged, despite a real dispatcher already being installed, the cached no-op dispatcher is queried which has no interest in logging the event. The stack trace where the interest is evaluated looks as follows.
I'm not very familiar with tracing internals, but it sounds like an issue in tracing instead of color-eyre, which should signal an error or ensure creation of The issue is also somewhat (but not quite) similar to tokio-rs/tracing#2400 A partial / interim workaround is to disable span trace capturing with env vars, until the default dispatcher is installed. std::env::set_var("RUST_SPANTRACE", "0");
color_eyre::install().unwrap();
let _ = color_eyre::eyre::eyre!("A very ignorable error, so we ignore it");
tracing_subscriber::fmt::init();
std::env::set_var("RUST_SPANTRACE", "1");
tracing::event!(tracing::Level::ERROR, "something happened"); |
Filed tokio-rs/tracing#2436 |
Ahhh that's what's going on. Took a while to find out what's happening / find a relevant issue. |
This is fixed upstream by tokio-rs/tracing#2593 (released in |
Simply put amazing 😁 |
Hello, I've been using
color_eyre
on a work project, and had experienced troubles with the logging (usingtracing
/tracing_subscriber
).What happening and what should happen ?
Observed Behavior: Creating a
eyre::Report
before initializing thetracing_subscriber
even if we're ignoring it makes subsequent logs disappear.Expected Behavior: The logs should still be printed, wether or not a
eyre::Report
is created.Why is this issue on
color_eyre
and not ontracing_subscriber
?While testing and trying to know what was happening, I switched to
stable_eyre
, and the issue fixed itself, so this must come fromcolor_eyre
.Here is a minimal reproduction of the bug:
and I'm using the following versions of crates in my
Cargo.toml
:Don't hesitate to ask any question :)
Thanks !
The text was updated successfully, but these errors were encountered: