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

Propagation Context Experiment Draft #8403

Closed
wants to merge 2 commits into from

Conversation

AbhiPrasad
Copy link
Member

ref #8352

This draft PR represents me playing around with the API of a propagation context (aka distributed tracing context).

To make tracing without performance work, we are required to always have some kind of storage mechanism for distributed tracing context. This propagation context right now is supplemented by the existence of a transaction, which exists as the vehicle to carry this information.

With TwP, we are looking to introduce a source of truth that carries this trace information, that then everything will read from. This source of truth lives on the scope, as it is expected to change with incoming requests (node) or meta tags (browser) changing the trace.

This PR will be closed with the actual PR afterwards, but just wanted a place I can look at my ideas in the time being.

@AbhiPrasad
Copy link
Member Author

Some things to think about

  1. Do we refactor out transaction.getDynamicSamplingContext and replace with a common parent method? We need a way to generate dsc (also lazily) from just the client options.

My initial idea is to put a DSC generating method on the hub, which can use both the client/scope to do this logic. The transaction can reference this method accordingly then.

  1. Should the scope expose explicit setters/getters or just HOC methods that return transforms of the propagation context? For example instead of getPropagationContext, you would call getTraceContextorgetDsc`. I'm shying away from multiple methods on the scope because it's bundle size inefficient.

  2. Scope cloning/updating - what is the behaviour we want. In my eyes: Scope.clone should inherit the current propagation context. Scope.update should also update it so you can use initialScope to set your own trace id (might be useful in some circumstances idk - maybe a little too powerful though)

@AbhiPrasad AbhiPrasad closed this Jun 28, 2023
AbhiPrasad added a commit that referenced this pull request Jun 29, 2023
ref #8352

For more details about PropagationContext, see
https://www.notion.so/sentry/Tracing-without-performance-efab307eb7f64e71a04f09dc72722530

Building off of work in both
#8403 and
#8418, this PR adds
`PropagationContext` and uses that to always set a trace context on
outgoing error events.

Currently if there is an active span on the scope, we automatically
attach that span's trace context to all outgoing events. Now, we want to
rely on either the active span or fallback to the propagation context to
ensure that there is always a trace being generated and propagated.

Next up we'll work on updating the node/browser SDKs to update the
propagation context. For example, we should update the propagation
context for node based on the incoming sentry-trace/baggage headers.
@AbhiPrasad AbhiPrasad deleted the abhi-propagation-context branch July 4, 2023 13:54
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.

1 participant