Summary

The spec defines db.response.status_code on command spans but not error.type, which the technical design lists alongside it at the same requirement level. Leaving it out was deliberate, because it duplicates exception.type. However the two are different kinds of thing: exception.type is an attribute on the exception event, while error.type is a span attribute. Following the OpenTelemetry semantic conventions verbatim means adding error.type and accepting that duplication.

Motivation

Who is the affected end user?

Driver teams implementing the spec, and application developers who filter or aggregate traces by error class.

How does this affect the end user?

error.type is the dimension OpenTelemetry backends group and alert on for failures. Carried only as an exception-event attribute, it cannot be queried at the span level. Drivers that emit it anyway have no shared definition of its value, so the same failure is labelled differently per language.

How likely is it that this problem or use case will occur?

Every failed command.

If the problem does occur, what are the consequences and how severe are they?

Moderate. No data or availability risk. Failure dashboards and alerting behave differently per driver, and a driver that adds the attribute later changes the shape of its traces.

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No. The attribute and its value have to be specified; a test alone would make one reading normative.

Acceptance Criteria

• The Command Span Attributes table lists error.type as a string, required if an error happens, matching how db.response.status_code is listed.
• The spec states the value: error.type SHOULD match db.response.status_code when the command failed with a server error, and otherwise SHOULD be the class name of the exception.
• The spec states that error.type MUST NOT be set when the command succeeds, and SHOULD have a low number of distinct values, per the semantic conventions.
• The spec states that error.type is a span attribute that deliberately duplicates information carried by exception.type on the exception event, and why: backends query the span dimension rather than the event.
• The spec states whether error.type applies to operation spans as well as command spans.
• A test covers a failing command carrying the attribute. In the server-error case the value is assertable, since it matches db.response.status_code; in the non-server-error case it is language specific, so only presence and type can be asserted.
• open-telemetry.md has a dated changelog entry.