Sentry is attaching Tracing Headers without running transactions

[DarkByteZero]

Sentry is attaching Tracing Headers without running transactions

[cleptric]

@AbhiPrasad the absence of the sampling flag delegates the sampling decision to the receiving SDK. There is a defined order of what takes precedence, defined in https://develop.sentry.dev/sdk/performance/#sampling and implemented here https://github.com/getsentry/sentry-go/blob/master/tracing.go#L427-L511.

[AbhiPrasad]

hey @DarkByteZero - attaching the headers is by intention given distributed tracing does not depend on performance monitoring (generating spans) in Sentry.

When there is no active pageload though the sentry trace should be not attaching a sampled flag. This is indicated by no -1 being attached to d1f4373147294b14ab220450dc8ca2c6-9f0c782faa520627, like we see in the earlier header acc3a2d245d4404789d4cabe533996d7-bbd6bd5567ae8a87-1.

The Go SDK should be parsing a sample rate of 0 if this is dropped, @cleptric could you help sanity check this?

[DarkByteZero]

I appreciate the intention behind attaching headers for distributed tracing, but what is the reason for sending these trace headers, if there isn't even a parent transaction in the sentry system collected. Another Problem is the frequency at with these traces are changed, like in my image you can see that multiple API requests are aggregated into one trace, but there is a big gap between them, this makes it difficult to debug.

[lforst]

@AbhiPrasad @DarkByteZero We need to change how we do trace propagation without active spans in the frontend. The current implementation has issues and leads to traces like @DarkByteZero outlined. These traces have absolutely no value.

Concretely, we have to do one of two things:

• Stop having an always-ambient trace propagation context.
• Stop picking up the context when performance is enabled.

[DarkByteZero]

hey @DarkByteZero - attaching the headers is by intention given distributed tracing does not depend on performance monitoring (generating spans) in Sentry.

When there is no active pageload though the sentry trace should be not attaching a sampled flag. This is indicated by no -1 being attached to d1f4373147294b14ab220450dc8ca2c6-9f0c782faa520627, like we see in the earlier header acc3a2d245d4404789d4cabe533996d7-bbd6bd5567ae8a87-1.

The Go SDK should be parsing a sample rate of 0 if this is dropped, @cleptric could you help sanity check this?

The GO SDK does not interpret the absence of the sampled flag as a sampled false. Actually, if it would do, all api transactions would not be sampled, which would be bad.

// updateFromSentryTrace parses a sentry-trace HTTP header (as returned by
// ToSentryTrace) and updates fields of the span. If the header cannot be
// recognized as valid, the span is left unchanged. The returned value indicates
// whether the span was updated.
func (s *Span) updateFromSentryTrace(header []byte) (updated bool) {
	m := sentryTracePattern.FindSubmatch(header)
	if m == nil {
		// no match
		return false
	}
	_, _ = hex.Decode(s.TraceID[:], m[1])
	_, _ = hex.Decode(s.ParentSpanID[:], m[2])
	if len(m[3]) != 0 {
		switch m[3][0] {
		case '0':
			s.Sampled = SampledFalse
		case '1':
			s.Sampled = SampledTrue
		}
	}
	return true
}

[lforst]

I think this issue right here is a symptom of the JS SDK having a buggy/confusing trace propagation when no spans are active. We will fix this in the upcoming major (v8). It will lead to slightly less connected-ness within your data but at least unrelated stuff isn't gonna be connected anymore.