-
Notifications
You must be signed in to change notification settings - Fork 123
Add exception.type to error events #243
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
base: v0.1.x
Are you sure you want to change the base?
Add exception.type to error events #243
Conversation
Make sure we always append `exception.type` to the span events any time we convert an error to an exception. This is required to make Datadog platform happy and avoid the "Missing error message and stack trace" error.
Current default branch is broken, failing the build. I am doing a change that I think is appropriate here, but open to feedback.
| status, | ||
| } => { | ||
| builder.attributes.get_or_insert(Vec::new()).push(key_value); | ||
| builder.status = status.clone(); |
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.
Please double-check this for me. At the moment, the default branch if failing to build, because the status field isn't properly matched. I think I am doing the right thing here, but if I should rather ignore the status instead of setting it on the builder, please let me know and I will make an update.
Use `Unknown` as an `exception.type` instead of `dyn ...` types as per our conversation in the original issue.
cijothomas
left a comment
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 don't think this should be fixed in this layer. If a particular attribute is required for a backend, then this can be solved by adding the missing pieces elsewhere- like OTel SDK or OTel Collector.
|
Can the otel SDK conditionally add information? As in if there is |
Not by default, unless it is required by the specification. But users can add things themselves. |
|
Just a bit of an update and some extra context. I had a bit of a chat in Discord and discussed how we can do this better. Ideally we would be able to utilize the Valuable crate in the tracing ecosystem to be able to preserve the type information all the way through. This will require some changes in the tracing/core itself and I am exploring how to make this happen. No significant progress thus far because I got some priority changes, but I will come back to this end of the week / start of next week and continue the exploration. |
Make sure we add
exception.typefield to span events any time we report an error as an exception.Motivation
This change is addressing the issue described in #242, where traces that are sent to Datadog that contained errors would not properly link and render, causing an error in Datadog's UI:
Missing error message and stack trace.Solution
Datadog apparently requires at least the
exception.messageandexception.typefields to be present.Closes #242
Closes tokio-rs/tracing#2648