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

Define Propagation-only Span to simplify active Span logic in Context. #994

Merged

Conversation

carlosalberto
Copy link
Contributor

@carlosalberto carlosalberto commented Sep 23, 2020

Fixes #949

Changes

Define the notion of a PropagatedSpan, which wraps a SpanContext, and can be leveraged to simplify the active Span logic when detecting the parent Span in a given Context (so we don't have to store a Span and a SpanContext in Context).

(Observe I tried to keep it as simple as possible in order to expedite this PR as much as possible ;) )

@carlosalberto
Copy link
Contributor Author

@Oberon00 @bogdandrutu @mwear Feedback applied. Please review ;)

@carlosalberto carlosalberto changed the title Define DefaultSpan to simplify active Span logic in Context. Define Propagation-only Span to simplify active Span logic in Context. Sep 23, 2020
Copy link
Member

@mwear mwear left a comment

Choose a reason for hiding this comment

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

LGTM

specification/trace/api.md Show resolved Hide resolved
specification/trace/api.md Outdated Show resolved Hide resolved
Copy link
Member

@Oberon00 Oberon00 left a comment

Choose a reason for hiding this comment

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

The "Note: MUST" thing should be cleared up, but approving in advance.

@carlosalberto
Copy link
Contributor Author

Renamed to PropagatedSpan, cc @anuraaga


The API MUST provide an operation for wrapping a `SpanContext` with an object
implementing the `Span` interface. This is done in order to expose a `SpanContext`
as a `Span` in operations such as in-process `Span` propagation.

If a new type is required for supporting this operation, it SHOULD be named `PropagatorOnlySpan`.
If a new type is required for supporting this operation, it SHOULD be named `PropagatedSpan`.
Copy link
Member

Choose a reason for hiding this comment

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

Please decide between "Propagated Span" and "PropagatedSpan"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Propagated Span is a concept, PropagatedSpan is the name (as Ruby does not need to expose it).

Copy link
Member

Choose a reason for hiding this comment

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

I would think it's cleaner if we named the concepted PropagatedSpan too, but this is only an nipick anyway (I approved the PR)

@bogdandrutu bogdandrutu merged commit d14c9b7 into open-telemetry:master Sep 24, 2020
tsloughter added a commit to tsloughter/opentelemetry-specification that referenced this pull request Oct 21, 2020
carlosalberto added a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
open-telemetry#994)

* Define DefaultSpan to simplify active Span in Context.

* Update CHANGELOG.

* Update specification/trace/api.md

Co-authored-by: Christian Neumüller <[email protected]>

* Update specification/trace/api.md

Co-authored-by: Christian Neumüller <[email protected]>

* Apply feedback.

* Specify the SDK must not override it.

* Update CHANGELOG.

* Rename to PropagatedSpan.

* More feedback.

Co-authored-by: Christian Neumüller <[email protected]>
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.

Having both local and remote span parents?
7 participants