Open dvoytenko opened 8 months ago
fwiw, OpenTelemetry Java SDK implementation of recordException
uses Throwable.printStackTrace()
which does include the full causal chain
It might be good to clarify a construction of the unified stack trace in other languages, since not all of them do this.
However, I also think that combining stack traces is not enough. The "cause" exceptions often have valuable metadata, such as HTTP status codes and other attributes. Ideally there'd be a way to preserve it all.
Please provide a comprehensive breakdown of what this would mean for all the languages OTel is implemented in. It is not obvious how this would apply to all languages, especially non-object-oriented languages or those that do not use exceptions as control flow.
In JavaScript, the errors can be chained and accessed using error.cause
. If someone needs the full stack, they are expected to interrogate error.cause
recursively - it's not an automatic behavior. We could document for an appropriate OTEL library to combine all stacks (see https://github.com/open-telemetry/opentelemetry-js/issues/4227). However, the issue might be deeper, since the errors also contain important metadata, including code
, name
, and other fields/attributes.
The data model for this could be presented as:
Error {
exception.type: "",
exception.message: "",
exception.stacktrace: "",
exception.cause: {
exception.type: "",
exception.message: "",
exception.stacktrace: "",
exception.cause: { ... }
}
}
However, it's not clear how to codify this in OTEL data model:
LogRecord
(https://github.com/open-telemetry/opentelemetry-specification/issues/622).
What are you trying to achieve?
Many languages support a concept of a chained exception. For instance, JavaScript has
Error.cause
. Java also hasThrowable.getCause()
. When present, is just as important (and often more so), than the wrapping exception. CurrentlyrecordException()
loses this information.It'd be valuable to clarify whether the relevant languages should support the
cause
and how.