You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.
Using this lovely library, and as such I've got a new use case (oh yay!), Currently when telling tracing to log in json by configuring it as such:
let chosen_level = match std::env::var("RUST_LOG_LEVEL").as_ref().map(String::as_str){Ok("off") => LevelFilter::OFF,Ok("error") => LevelFilter::ERROR,Ok("warn") => LevelFilter::WARN,Ok("debug") => LevelFilter::DEBUG,Ok("trace") => LevelFilter::TRACE,
_ => LevelFilter::INFO,};let fmt_layer = fmt_layer().with_target(false);let filter_layer = EnvFilter::from_default_env().add_directive(chosen_level.into());
tracing_subscriber::registry().with(filter_layer).with(fmt_layer.json()).with(ErrorLayer::default()).init();let res = get_tasks(project_root_path, etype);ifletErr(reportable /*: Report*/) = res {
tracing::error!("{:?}", e);}
you get the following:
{
"timestamp": "Dec 06 00:39:39.365",
"level": "ERROR",
"fields": {
"message": "\n 0: \u001b[91mpyra::starlark::loop: break used outside of a loop\u001b[0m\n\nLocation:\n\u001b[35msrc/diagnostic/starlark/critical_semantic.rs\u001b[0m:\u001b[35m42\u001b[0m\n\n\u001b[34m\u001b[1m-->\u001b[0m /home/cynthia/projects/personal/pyra/.github/pyra.star:4:3\n\u001b[34m\u001b[1m |\u001b[0m\n...\n\u001b[34m\u001b[1m7 |\u001b[0m break\n\u001b[34m\u001b[1m |\u001b[0m\u001b[31m\u001b[1m ^^^^^\u001b[0m \u001b[31m\u001b[1mthe break keyword is reserved, and can ony be used in a loop\u001b[0m\n\u001b[34m\u001b[1m |\u001b[0m\n\n\u001b[96mSuggestion\u001b[0m: The indentation is less than the line before, perhaps missing an indent?"
}
}
These are the normal fields as tracing for any log message, and if you notice the main error content is all in "message". I'm curious though if there's a way with a Report object to reverse engineer it back to the "sections"/"notes" that compose that Report'able object so I can say create a json field, one for each section/note/etc. Curious if you have any thoughts?
The text was updated successfully, but these errors were encountered:
there are a few ways to approach this imo. We can absolutely make error reports output in json instead of as plain text, the question is when? Do we do it all the time or based on certain formatting flags? I'm not sure if we'd be able to trigger the specific formatting flags we care about when logging via tracing so it may have to be an always on thing, which would mean all errors reported, via tracing or otherwise, would be formatted in json. Would this be okay for your use case?
Yeah, that's more than fine! It's actually in a similar use case to reporting span traces I filed awhile back. I check an env var RUST_LOG_FORMAT and if it's set to JSON I want the entire output to be JSON (one object per line so it works with things like jq out of the box).
Using this lovely library, and as such I've got a new use case (oh yay!), Currently when telling tracing to log in json by configuring it as such:
you get the following:
These are the normal fields as tracing for any log message, and if you notice the main error content is all in "message". I'm curious though if there's a way with a
Report
object to reverse engineer it back to the "sections"/"notes" that compose that Report'able object so I can say create a json field, one for each section/note/etc. Curious if you have any thoughts?The text was updated successfully, but these errors were encountered: