should StatusCanonicalCode be applied for rpc?

[eddynaka]

What are you trying to achieve?

After the merge of this PR: #966, we can see that the StatusCanonicalCode got changed to Error, Unset, and Ok.

But, if we see the rpc status: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/rpc.md#status, they kept the same.

Additional context.

Should the status be the same? How should we map the rpc status to the new StatusCanonicalCode? For example: Unkown is an error or an unset status?

cc: @cijothomas @reyang

[cijothomas]

@tedsuo

[arminru]

Good catch, this needs to be updated. Thanks @eddynaka!

[arminru]

In order to resolve this, we'll need to do two things:

1. Add a mapping from GRPC Status Codes to our new OTel Status Code (Unset, Ok, Error), e.g.

• OK --> Ok
• CANCELLED and UNKNOWN --> undefined (up to the user) or leaving Unset
• all the others --> Error

2. Add a new attribute (e.g., rpc.grpc.status_code) to store the GRPC Status Code, which would otherwise be lost now that we have a different and considerably reduced set of Status Codes in OTel

[eddynaka]

Hi @arminru , thanks for mapping!

Do you have a timeline to be official in the spec?

[Oberon00]

@arminru I think the mapping will have to match the mapping we have defined in the proto, see open-telemetry/opentelemetry-proto#224. And there AFAIK the current proposal is OK -> UNSET, everything else -> ERROR. EDIT: Oh, we have the reverse mapping there and it is not unambiguously reversible because both unset and ok map to OK. But we should be consistent, and should never set Ok from instrumentation.

[andrewhsu]

@carlosalberto from the issue triage mtg today, assigning to you since you previously worked in this area

[eddynaka]

Just to get a clear response. Would that be right the mapping below?

For HttpStatusCode:

• >= 100 && <= 399 -> UNSET
• ERROR (otherwise)

For RPC:

• OK -> UNSET
• ERROR (otherwise)

[Oberon00]

For HTTP, the mapping is already defined (indeed like you describe it) here: https://github.com/open-telemetry/opentelemetry-specification/blob/4b19e006ede63471103925edc6a15ab1d7579944/specification/trace/semantic_conventions/http.md#status

For RPC, I think that mapping makes sense, but we need to specify it in the semantic conventions. A PR would be welcome for that 😃