-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Status to be consistent with Link and Event #1067
Changes from 6 commits
651a1fb
f674c92
a4c1ea5
1169d75
4735730
9a094f3
deffb44
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,11 +33,6 @@ Table of Contents | |
* [Record Exception](#record-exception) | ||
* [Span lifetime](#span-lifetime) | ||
* [Propagated Span creation](#propagated-span-creation) | ||
* [Status](#status) | ||
* [StatusCanonicalCode](#statuscanonicalcode) | ||
* [Status creation](#status-creation) | ||
* [GetCanonicalCode](#getcanonicalcode) | ||
* [GetDescription](#getdescription) | ||
* [SpanKind](#spankind) | ||
* [Concurrency](#concurrency) | ||
* [Included Propagators](#included-propagators) | ||
|
@@ -496,16 +491,50 @@ Note that [`RecordException`](#record-exception) is a specialized variant of | |
|
||
#### Set Status | ||
|
||
Sets the [`Status`](#status) of the `Span`. If used, this will override the | ||
default `Span` status, which is `OK`. | ||
Sets the `Status` of the `Span`. If used, this will override the default `Span` | ||
status, which is `Unset`. | ||
|
||
Only the value of the last call will be recorded, and implementations are free | ||
to ignore previous calls. | ||
`Status` is semantically defined by the following properties: | ||
|
||
- `StatusCanonicalCode` that represents the canonical set of `Status` codes. | ||
- Optional `Description` that provides a descriptive message of the `Status`. | ||
|
||
`StatusCanonicalCode` has the following values: | ||
|
||
- `Unset` | ||
- The default status. | ||
- `Ok` | ||
- The operation has been validated by an Application developers or Operator to | ||
bogdandrutu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
have completed successfully. | ||
- `Error` | ||
- The operation contains an error. | ||
|
||
The Span interface MUST provide: | ||
|
||
- An API to set the `Status` where the new status is the only argument. This | ||
SHOULD be called `SetStatus`. | ||
- An API to set the `Status`. This SHOULD be called `SetStatus`. | ||
This API takes the `StatusCanonicalCode`, and optional `Description`, | ||
either as individual parameters or as an immutable object encapsulating them, | ||
whichever is most appropriate for the language. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not following - why would analysis tools generate errors? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question, I was not changing this, will file the issue #1068 to track this. |
||
|
||
Only the value of the last call will be recorded, and implementations are free | ||
to ignore previous calls. | ||
Comment on lines
+536
to
+537
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is only taken over but could be refined to be worded consistently (MUST/SHOULD/MAY) either here or in a follow-up. |
||
|
||
#### UpdateName | ||
|
||
|
@@ -594,62 +623,6 @@ The remaining functionality of `Span` MUST be defined as no-op operations. | |
|
||
This functionality MUST be fully implemented in the API, and SHOULD NOT be overridable. | ||
|
||
## Status | ||
|
||
`Status` interface represents the status of a finished `Span`. It's composed of | ||
a canonical code, and an optional descriptive message. | ||
|
||
### StatusCanonicalCode | ||
|
||
`StatusCanonicalCode` represents the canonical set of status codes of a finished | ||
`Span`. | ||
|
||
- `Unset` | ||
- The default status. | ||
- `Error` | ||
- The operation contains an error. | ||
- `Ok` | ||
- The operation has been validated by an Application developers or Operator to | ||
have completed successfully, or contain | ||
|
||
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. | ||
|
||
### Status creation | ||
|
||
API MUST provide a way to create a new `Status`. | ||
|
||
Required parameters | ||
|
||
- `StatusCanonicalCode` of this `Status`. | ||
|
||
Optional parameters | ||
|
||
- Description of this `Status`. | ||
|
||
### GetCanonicalCode | ||
|
||
Returns the `StatusCanonicalCode` of this `Status`. | ||
|
||
### GetDescription | ||
|
||
Returns the description of this `Status`. | ||
Languages should follow their usual conventions on whether to return `null` or an empty string here if no description was given. | ||
|
||
## SpanKind | ||
|
||
`SpanKind` describes the relationship between the Span, its parents, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fixing a bug in the specs (I guess)