-
Notifications
You must be signed in to change notification settings - Fork 653
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
Add indicator if SpanContext was propagated from remote parent #516
Add indicator if SpanContext was propagated from remote parent #516
Conversation
Looks like we have an unrelated flaky test (EDIT: Actually that was pip failing to download something. Maybe we can set it to retry once):
I re-triggered the build. |
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.
Two small -not blocking- nits. LGTM!
@@ -86,10 +86,12 @@ def test_extract_multi_header(self): | |||
new_carrier[FORMAT.SPAN_ID_KEY], | |||
b3_format.format_span_id(child.context.span_id), | |||
) | |||
self.assertFalse(child.context.is_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.
I don't think this check is needed. child
is created from a SpanContext
extracted from the carrier, so whether is_remote
is False
or True
depends on the Span
implementation (that you are already testing in test_span_context_remote_flag
) and not on the propagator one.
Same consideration for all the cases where child.is_remote
is tested.
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.
That's an interesting nuance. Are we expecting that different Span SDKs will handle this behavior differently? I guess I understood it as even different Span implementations SHOULD still adhere to the span propagation behavior.
Even the link this PR is referring to lives in the "API" section: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#spancontext. So theoretically different implementations should still provide similar behavior.
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 agree that a test checking that the is_remote
flag is not propagated to children is useful, however this is not the place to such test, that behavior depends on the tracer implementation and not in the propagator one.
@@ -319,6 +319,7 @@ class SpanContext: | |||
span_id: This span's ID. | |||
trace_flags: Trace options to propagate. | |||
trace_state: Tracing-system-specific info to propagate. | |||
is_remote: Indicator if propagated from a remote parent |
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.
is_remote: Indicator if propagated from a remote parent | |
is_remote: Indicator if propagated from a remote parent. |
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.
is_remote: Indicator if propagated from a remote parent | |
is_remote: True if propagated from a remote parent. |
* remove redundant assertions in tests * adapt doc string for is_remote flag in SpanContext
@@ -378,6 +378,12 @@ def test_default_span_resource(self): | |||
# pylint: disable=protected-access | |||
self.assertIs(span.resource, resources._EMPTY_RESOURCE) | |||
|
|||
def test_span_context_remote_flag(self): |
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.
maybe add a docstring saying that the expected behavior is is_remote is False by default? I guess it's implicit, I just like having some human description so I can verify the intended behavior.
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.
Actually, I think there should not be a default for is_remote
. And if any, the default should be true
. This flag might have security implications, e.g. samplers may trust a sampled=True flag on a is_remote=False SpanContext. If the is_remote flag is wrongly False, this might lead to a Denial of Service vulnerability.
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 can definitely see that argument, although I'm wondering if denial of service is a concern, there isn't a more robust way of dealing with that. This also assumes that the adapters (include internal/custom ones) also properly use the is_remote flag, which is impossible to enforce.
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.
on the other hand, I feel like is_remote=True as the default is unusual behavior, as the remote span is much more of a special case, and currently users are creating/starting spans with no arguments, which would then make then remote spans by default unless one is aware of that flag, and sets it everywhere.
We may need more opinions here, but I think the default being false ensures minimal friction for usage of the opentelemetry APIs.
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.
Sorry, this was a misunderstanding on my side! 🙈
I thought we were talking about manually creating a SpanContext. For starting a new span, having is_remote=False on its SpanContext is the only sane thing to do (and this should not be configurable).
@@ -86,10 +86,12 @@ def test_extract_multi_header(self): | |||
new_carrier[FORMAT.SPAN_ID_KEY], | |||
b3_format.format_span_id(child.context.span_id), | |||
) | |||
self.assertFalse(child.context.is_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.
That's an interesting nuance. Are we expecting that different Span SDKs will handle this behavior differently? I guess I understood it as even different Span implementations SHOULD still adhere to the span propagation behavior.
Even the link this PR is referring to lives in the "API" section: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#spancontext. So theoretically different implementations should still provide similar behavior.
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.
Thanks for the hard work! I think there's a little bit of clarification in the Spec I'd like to verify before merging, but I think this does the current intended behavior.
@mauriciovasquezbernal I'd argue the test that was removed should be re-added, but maybe that needs clarification in the spec. issue filed: open-telemetry/opentelemetry-specification#523
Codecov Report
@@ Coverage Diff @@
## master #516 +/- ##
=======================================
Coverage 89.47% 89.47%
=======================================
Files 43 43
Lines 2213 2214 +1
Branches 250 250
=======================================
+ Hits 1980 1981 +1
Misses 161 161
Partials 72 72
Continue to review full report at Codecov.
|
span_id: int, | ||
trace_flags: "TraceFlags" = DEFAULT_TRACE_OPTIONS, | ||
trace_state: "TraceState" = DEFAULT_TRACE_STATE, | ||
is_remote: bool = False, |
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 suggest not having a default here, for the reasons outlined in https://github.com/open-telemetry/opentelemetry-python/pull/516/files/9b92b7aa1e08be55d309ff2b0de266df0ee5fb91#r396611236
span_id: int, | |
trace_flags: "TraceFlags" = DEFAULT_TRACE_OPTIONS, | |
trace_state: "TraceState" = DEFAULT_TRACE_STATE, | |
is_remote: bool = False, | |
span_id: int, | |
is_remote: bool, | |
trace_flags: "TraceFlags" = DEFAULT_TRACE_OPTIONS, | |
trace_state: "TraceState" = DEFAULT_TRACE_STATE, | |
…telemetry#516) According to the spec a SpanContext should have an indicator if it was propagated from a remote parent. Introduces an is_remote flag on the SpanContext which gets set when the SpanContext is extracted in a propagaton.
* fix: add missing dev dependencies * fix: lint
According to the spec a
SpanContext
should have an indicator if it was propagated from a remote parent.This PR introduces an
is_remote
flag on theSpanContext
which gets set when theSpanContext
is extracted in a propagator.