-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
The tests were not working properly. 1. Some test was setting a global subscriber, this could lead to racy conditions with other tests. 2. A logging test called `process::exit` which is completly wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (and thank you!)
Left a few suggestions.
let max_level_hint = Layer::<FmtSubscriber>::max_level_hint(&env_filter); | ||
|
||
let max_level = max_level.unwrap_or_else(|| match max_level_hint { | ||
let max_level = match max_level_hint { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use tracing_subscriber::filter::LevelFilter
and clean up some line noise here?
client/tracing/src/lib.rs
Outdated
|
||
let event3 = events.lock().remove(0); | ||
assert!(event3.parent_id.is_none()); | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would help readability a bit if you reversed the conditions, so that this else
block became the if
block. That way readers can read the code in the execution order.
@@ -456,7 +455,7 @@ mod tests { | |||
Box::new(handler), | |||
"test_target", | |||
); | |||
let subscriber = tracing_subscriber::fmt().finish().with(layer); | |||
let subscriber = tracing_subscriber::fmt().with_writer(std::io::sink).finish().with(layer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me se if I understand this correctly: instead of having our own TestSubscriber
, you create one that writes to what is essentially /dev/null
(will always succeed) and access the spans/events through the Arc'd (like before).
That seems like a much better solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I first thought that this would be one of the problems. In the end this is no problem at all, but should make the output cleaner.
Co-authored-by: David <dvdplm@gmail.com>
env_filter = parse_user_directives(env_filter, directives)?; | ||
} | ||
|
||
if let Some(profiling_targets) = profiling_targets { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like I am having a déjà vu. Didn't this code use to be pretty much like this? (including the forced sc_tracing=trace
directive).
* Fix tracing tests The tests were not working properly. 1. Some test was setting a global subscriber, this could lead to racy conditions with other tests. 2. A logging test called `process::exit` which is completly wrong. * Update client/tracing/src/lib.rs Co-authored-by: David <dvdplm@gmail.com> * Review comments Co-authored-by: David <dvdplm@gmail.com>
* Fix tracing tests (#8022) * Fix tracing tests The tests were not working properly. 1. Some test was setting a global subscriber, this could lead to racy conditions with other tests. 2. A logging test called `process::exit` which is completly wrong. * Update client/tracing/src/lib.rs Co-authored-by: David <dvdplm@gmail.com> * Review comments Co-authored-by: David <dvdplm@gmail.com> * Fix tracing spans are not being forwarded to spawned task (#8009) * Fix tracing spans are not being forwarded to spawned task There is a bug that tracing spans are not forwarded to spawned task. The problem was that only the telemetry span was forwarded. The solution to this is to use the tracing provided `in_current_span` to capture the current active span and pass the telemetry span explictely. We will now always enter the span when the future is polled. This is essentially the same strategy as tracing is doing with its `Instrumented`, but now extended for our use case with having multiple spans active. * More tests * Proper test for telemetry and prefix span * WIP * Fix test (need to create & enter the span at the same time) * WIP * Remove telemtry_span from sc_service config * CLEANUP * Update comment * Incorrect indent * More meaningful name * Dedent * Naming XD * Attempt to make a more complete test * lint * Missing licenses * Remove user data * CLEANUP * Apply suggestions from code review Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> * CLEANUP * Apply suggestion * Update bin/node/cli/tests/telemetry.rs Co-authored-by: David <dvdplm@gmail.com> * Wrapping lines Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com> Co-authored-by: David <dvdplm@gmail.com>
The tests were not working properly.
Some test was setting a global subscriber, this could lead to racy
conditions with other tests.
A logging test called
process::exit
which is completly wrong.