Conversation
|
Some things to think about
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.
|
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.
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.