Delete requirement to generate new trace/span id if an invalid id is received#444
Merged
tigrannajaryan merged 1 commit intoJan 20, 2023
Conversation
…received This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
jmacd
approved these changes
Jan 10, 2023
yurishkuro
approved these changes
Jan 10, 2023
jack-berg
approved these changes
Jan 11, 2023
Aneurysm9
approved these changes
Jan 11, 2023
carlosalberto
approved these changes
Jan 12, 2023
Member
Author
|
I will keep this open for a few more days and then will merge if there are no objections. |
Oberon00
reviewed
Jan 16, 2023
arminru
approved these changes
Jan 16, 2023
mx-psi
approved these changes
Jan 17, 2023
Oberon00
approved these changes
Jan 17, 2023
Member
Author
|
@bogdandrutu PTAL. |
bogdandrutu
approved these changes
Jan 20, 2023
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this pull request
Jun 21, 2024
…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this pull request
Jun 21, 2024
…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this pull request
Jun 21, 2024
…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
VinozzZ
pushed a commit
to VinozzZ/opentelemetry-proto
that referenced
this pull request
Jun 21, 2024
…received (open-telemetry#444) This is considered an bug in the spec that was uncovered in the discussion here: open-telemetry#442 (comment) I did some spelunking and the "generate" recommendation comes from the very first commit: open-telemetry@b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is considered an bug in the spec that was uncovered in the discussion here: #442 (comment)
I did some spelunking and the "generate" recommendation comes from the very first commit: b5bcfff#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus open-telemetry/opentelemetry-java#134 and in OpenCensus the wording first time appeared here census-instrumentation/opencensus-proto#160 (authored by @SergeyKanzhelev, merged by @bogdandrutu).
We are deleting the requirement to generate a new trace id or span id if an invalid id is received. Instead the receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid data), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.