OTLP/JSON: Clarify behavior when traceid/spanid fields are not present or not valid #3040
Assignees
Labels
spec:protocol
Related to the specification/protocol directory
Comments
tigrannajaryan
added
the
spec:protocol
tigrannajaryan
added a commit
to tigrannajaryan/opentelemetry-proto
that referenced
this issue
Jan 3, 2023
…ields Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
This was referenced Jan 3, 2023
tigrannajaryan
added a commit
to tigrannajaryan/opentelemetry-proto
that referenced
this issue
Jan 20, 2023
…ields Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
tigrannajaryan
added a commit
to tigrannajaryan/opentelemetry-proto
that referenced
this issue
Jan 20, 2023
…ields Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
tigrannajaryan
added a commit
to tigrannajaryan/opentelemetry-proto
that referenced
this issue
Jan 20, 2023
…ields Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
tigrannajaryan
added a commit
to open-telemetry/opentelemetry-proto
that referenced
this issue
Jan 27, 2023
…ields (#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this issue
Jun 21, 2024
…ields (open-telemetry#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this issue
Jun 21, 2024
…ields (open-telemetry#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this issue
Jun 21, 2024
…ields (open-telemetry#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this issue
Jun 21, 2024
…ields (open-telemetry#442) Resolves open-telemetry/opentelemetry-specification#3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The discussion here revealed that we do not have clear enough definition of what happens the traceid/spanid fields are not present or not valid in the JSON payload.
This needs to be clarified before we can declare OTLP/JSON Stable.
The text was updated successfully, but these errors were encountered: