-
Notifications
You must be signed in to change notification settings - Fork 839
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
Validate the span id and trace id when creating the SpanContext #2728
Conversation
And, remove that extra validation from propagators.
|
if (SpanId.isValid(spanIdHex) && TraceId.isValid(traceIdHex)) { | ||
return createInternal(traceIdHex, spanIdHex, traceFlags, traceState, remote); | ||
} | ||
return createInternal( |
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.
Should we return the INVALID SC?
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.
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
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.
So we either drop everything or we keep everything that is valid. I think the current implementation is in the middle and not ideal
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.
There were tests depending on this behavior. I'll need to figure out what they were trying to accomplish.
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.
I think I know why. There are 2 cases:
- is invalid hex string - in this case I think we should return SpanContext.getInvalid()
- 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.
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.
yes...this will take a bit of research that we can create a follow-up issue to deal with, I think.
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.
Added #2751
return new AutoValue_ImmutableSpanContext( | ||
traceId, spanId, traceFlags, traceState, /* remote$= */ remote); |
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.
Now that you calculate the isValid it can be a property in the AutoValue so no need to recalculate that or to use memoization.
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.
excellent idea. let's create an issue to track that optimization.
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.
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); |
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.
Consider to remove the comment /* remote$= */
not needed
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.
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.
Added issues to track the optimization and investigation of the slightly strange half-way-valid usage. |
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