Problem Statement
It would be useful to use sentryhttpclient.NewSentryRoundTripper to automatically create http.client spans for outbound requests without necessarily propagating Sentry tracing headers (sentry-trace and baggage) to the destination.
One use case is monitoring requests to third-party services. Those requests may still be useful to instrument, even when the destination is not part of the distributed trace and should not receive Sentry tracing headers.
WithTracePropagationTargets currently appears to couple these two behaviors. If a request does not match a configured propagation target, it bypasses the Sentry HTTP instrumentation entirely, so no http.client span is created.
This means there is currently no way to retain automatic request instrumentation while limiting trace propagation to specific URLs.
Solution Brainstorm
WithTracePropagationTargets could control only whether tracing headers are attached to the outgoing request, while the RoundTripper continues to create http.client spans regardless of whether the URL matches a propagation target.
For example:
roundTripper := sentryhttpclient.NewSentryRoundTripper(
http.DefaultTransport,
sentryhttpclient.WithTracePropagationTargets([]string{
"internal.service.local",
}),
)
could result in:
internal.service.local
→ create http.client span
→ propagate tracing headers
third-party.example.com
→ create http.client span
→ do not propagate tracing headers
Alternatively, a separate option could explicitly disable propagation while retaining instrumentation, for example:
sentryhttpclient.WithTracePropagation(false)
Separating these behaviors would allow http.client spans to be collected for third-party requests while still controlling where tracing information is propagated.
Problem Statement
It would be useful to use sentryhttpclient.NewSentryRoundTripper to automatically create http.client spans for outbound requests without necessarily propagating Sentry tracing headers (sentry-trace and baggage) to the destination.
One use case is monitoring requests to third-party services. Those requests may still be useful to instrument, even when the destination is not part of the distributed trace and should not receive Sentry tracing headers.
WithTracePropagationTargets currently appears to couple these two behaviors. If a request does not match a configured propagation target, it bypasses the Sentry HTTP instrumentation entirely, so no http.client span is created.
This means there is currently no way to retain automatic request instrumentation while limiting trace propagation to specific URLs.
Solution Brainstorm
WithTracePropagationTargets could control only whether tracing headers are attached to the outgoing request, while the RoundTripper continues to create http.client spans regardless of whether the URL matches a propagation target.
For example:
roundTripper := sentryhttpclient.NewSentryRoundTripper(
http.DefaultTransport,
sentryhttpclient.WithTracePropagationTargets([]string{
"internal.service.local",
}),
)
could result in:
internal.service.local
→ create http.client span
→ propagate tracing headers
third-party.example.com
→ create http.client span
→ do not propagate tracing headers
Alternatively, a separate option could explicitly disable propagation while retaining instrumentation, for example:
sentryhttpclient.WithTracePropagation(false)
Separating these behaviors would allow http.client spans to be collected for third-party requests while still controlling where tracing information is propagated.