Skip to content
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

Validate the span id and trace id when creating the SpanContext #2728

Merged
merged 1 commit into from
Feb 8, 2021

Conversation

jkwatson
Copy link
Contributor

@jkwatson jkwatson commented Feb 6, 2021

And, remove that extra validation from propagators.

I didn't remove it from the B3 Propagator(s) yet... that will take a bit more work to untangle.

Resolves #2719

And, remove that extra validation from propagators.
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Feb 6, 2021

CLA Signed

The committers are authorized under a signed CLA.

if (SpanId.isValid(spanIdHex) && TraceId.isValid(traceIdHex)) {
return createInternal(traceIdHex, spanIdHex, traceFlags, traceState, remote);
}
return createInternal(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we return the INVALID SC?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that it may seem strange to propagate flags and state but not one of the IDs if the other one is invalid

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we either drop everything or we keep everything that is valid. I think the current implementation is in the middle and not ideal

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There were tests depending on this behavior. I'll need to figure out what they were trying to accomplish.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I know why. There are 2 cases:

  1. is invalid hex string - in this case I think we should return SpanContext.getInvalid()
  2. is equal with TraceIs.getInvalid() - this is used in tests I guess, probably we should preserve all values.

Not sure if that is the behavior we want, but this is a guess for the problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes...this will take a bit of research that we can create a follow-up issue to deal with, I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added #2751

Comment on lines +26 to +27
return new AutoValue_ImmutableSpanContext(
traceId, spanId, traceFlags, traceState, /* remote$= */ remote);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that you calculate the isValid it can be a property in the AutoValue so no need to recalculate that or to use memoization.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

excellent idea. let's create an issue to track that optimization.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private static AutoValue_ImmutableSpanContext createInternal(
String traceId, String spanId, TraceFlags traceFlags, TraceState traceState, boolean remote) {
return new AutoValue_ImmutableSpanContext(
traceId, spanId, traceFlags, traceState, /* remote$= */ remote);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider to remove the comment /* remote$= */ not needed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it always baffles me when errorprone will complain about this, and when it won't. I'm sure I added it because errorprone complained, but there might have been some refactoring after that.

@jkwatson
Copy link
Contributor Author

jkwatson commented Feb 8, 2021

Added issues to track the optimization and investigation of the slightly strange half-way-valid usage.

@jkwatson jkwatson merged commit d34b66b into open-telemetry:main Feb 8, 2021
@jkwatson jkwatson deleted the validate_span_context_bits branch February 8, 2021 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SpanContext does not respect the specification contract
3 participants