-
We are trying to collect traces using the Otel-collector. In this project we see that the error codes are defined as: const (
// Unset is the default status code.
Unset Code = 0
// Error indicates the operation contains an error.
Error Code = 1
// Ok indicates operation has been validated by an Application developers
// or Operator to have completed successfully, or contain no error.
Ok Code = 2
maxCode = 3
) However, in opentelemetry-collector they are defined as: var Status_StatusCode_value = map[string]int32{
"STATUS_CODE_UNSET": 0,
"STATUS_CODE_OK": 1,
"STATUS_CODE_ERROR": 2,
} Is there a reason why this library seems to follow a different convention to the defined in the spec and different from the one in opentelemetry-collector? As extra context we are trying to move from openCensus to Otel, and we are seeing inconsistency with the way status is handled |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The specification does not give normative guidelines for what enum values should be, rather just what status values should be available. Both the opentelemetry-go, OTLP, and collector conform to the specification in this way. We have discussed this in a prior issue and reached community consensus that we do not want to synchronize the underlying type enum value. Instead we want to encourage users to use the API to access and convert the status type. This is intentional. Casting to the underlying type to convert to the OTLP is not guaranteed to be forwards/backwards compatible. The API should be used to convert named values because named values are the only thing that have semantic meaning. |
Beta Was this translation helpful? Give feedback.
The specification does not give normative guidelines for what enum values should be, rather just what status values should be available. Both the opentelemetry-go, OTLP, and collector conform to the specification in this way.
We have discussed this in a prior issue and reached community consensus that we do not want to synchronize the underlying type enum value. Instead we want to encourage users to use the API to access and convert the status type. This is intentional. Casting to the underlying type to convert to the OTLP is not guaranteed to be forwards/backwards compatible. The API should be used to convert named values because named values are the only thing that have semantic meaning.