Spec Conformance Review: Span Set Status

[MrAlias]

• Review SetStatus operation for a Span and identify all normative requirements it contains.
• Validate our implementation of the specification to conform or not. If it conforms, document the conformity here. If it does not open an Issue or PR track the work.

[MrAlias]

SetStatu

Status is structurally defined by the following properties:

• StatusCode, one of the values listed below.
• Optional Description that provides a descriptive message of the Status.
  Description MUST only be used with the Error StatusCode value.

We need to not set the description if not Error

StatusCode is one of the following values:

• Unset
  • The default status.
• Ok
  • The operation has been validated by an Application developer or Operator to have completed successfully.
• Error
  • The operation contains an error.

Our codes conform

The Span interface MUST provide:

• An API to set the Status.
  This SHOULD be called SetStatus.
  This API takes the StatusCode, and an optional Description, either as individual parameters or as an immutable object encapsulating them, whichever is most appropriate for the language.
  Description MUST be IGNORED for StatusCode Ok & Unset values.

We need to ignore the description if not Error

The status code SHOULD remain unset, except for the following circumstances:

When the status is set to ERROR by Instrumentation Libraries, the status codes SHOULD be documented and predictable.
The status code should only be set to ERROR according to the rules defined within the semantic conventions.
For operations not covered by the semantic conventions, Instrumentation Libraries SHOULD publish their own conventions, including status codes.
Generally, Instrumentation Libraries SHOULD NOT set the status code to Ok, unless explicitly configured to do so.
Instrumention libraries SHOULD leave the status code as Unset unless there is an error, as described above.
Application developers and Operators may set the status code to Ok.
Analysis tools SHOULD respond to an Ok status by suppressing any errors they would otherwise generate.
For example, to suppress noisy errors such as 404s.
Only the value of the last call will be recorded, and implementations are free to ignore previous calls.

These requirements are for instrumentors, but as a sanity check:

• We only set status to codes.Ok in tests
• We set codes.Error for:
  • HTTP status codes in semconv - this seems in line with current semantic conventions
  • When we record an error. I'm not sure we should be doing this: https://cloud-native.slack.com/archives/C01N7PP1THC/p1614978903067900. Tracking needed change here