oteps
oteps copied to clipboard
Span Status Improvements (without errors)
We recently discussed OTEP #123 at the error working group and agreed it introduced some good ideas, but they were coupled with error reporting. Exception data was handled by https://github.com/open-telemetry/opentelemetry-specification/pull/697 and the successHint
inspired this error.hint
PR: https://github.com/open-telemetry/opentelemetry-specification/pull/822.
There are currently proposals to remove Span.status (see: https://github.com/open-telemetry/opentelemetry-specification/issues/706). If we decide to keep it, this adaption of OTEP-123 could be an improvement worth considering.
See the original OTEP for commentary and rationale.
There are currently proposals to remove Span.status (see: open-telemetry/opentelemetry-specification#706). If we decide to keep it, this adaption of OTEP-123 could be an improvement worth considering.
What is the Error Working Group position on this? Do we remove Status? Do we keep it but improve? Do we have 2 opposing proposals because Error Working Group was not able to come to a concensus on this?
I would like to have more clarity on this otherwise I am not sure which of the opposing proposals to actively pursue. The OTEP to remove Status is also submitted: https://github.com/open-telemetry/oteps/pull/134
Just to be clear: I am happy if the goal is to discuss 2 proposals in parallel and chose a winning one, just want to understand if that is the intent here.
We had much more agreement on removing current status code, than on its replacement. So we want to remove Google RPC code bases status before GA, that is what my otep is about. And separately we discuss what should we put instead of it. Either before GA or after. And for that there are several options. One is this PR. Another is open-telemetry/opentelemetry-specification#822
I think we need to require having a reasonable replacement for conveying erroneous state in the Span. I believe this is needed before GA. Ideally we will first know what is this replacement before removing the Status. I am also happy if the answer is that we don't need any replacement, but I would like that analysis to also be done before removal of the Status.
@mwear Should this be closed in favor of #136 ?
@mwear please reopen if you change your mind about this