cc @hangy since I pinged on a merged PR

• feat: Add W3C traceparent support to tracing client and utils #4084 (comment)

Looks like he's OK for us just to remove that... it's a pity 😞

FWIW I don't use it, as I implemented the issue/feature for other people that might need it. Since we can't know if anyone else depends on it, it's still a breaking change

Thanks for the reply and more context. And sorry for the confusion we've caused. We should have closed the original issue earlier.
I am thinking about three options:

• remove it soon, so that it isn't out in too many versions
• remove in the next major release
• make the feature opt-in (previous behavior per default)
  • not necessarily via a new SentryOption property, as it's getting quite large and not to make this opt-in "too discoverable"
  • but perhaps via an AppContext switch, still documented, but as a more advanced opt-in
  • but there is an argument to be made about testability and maintainability

I think the goal is to get rid of it by the next major version, at the latest.

It's been out in the wild for about a week so I think we're probably pretty safe to just remove it.

If anyone complains, then we can add it back as an OptIn and decide how we want to do that based on why folks want it back.

Kinda a bummer 😔

Seems like there should be some ways to allow traceparent inheritance from an allowlist, or other ways of avoiding this "external services sending trace data" issue

Hm, I'm not sure this is something we can unilaterally decide to support in just the .NET SDK. @cleptric do you have a bit more context around this that we can share with @ericsampson ?

@ericsampson what is the scenario where you would need/want to propagate trace context either to Sentry or from Sentry using the traceparent header?

We no longer want to support traceparent in any of our SDKs for the time being. All our SDKs support trace propagation via the sentry-trace header. If someone needs to have a mixed setup with some services only emitting a traceparent header, we have ample of APIs available to allow these cases to be supported manually.
The current state of affairs is that we see hundreds-of-thousands of useless traces being generated by unrelated 3rd parties, blasting their traceparent header into the world without any considerations about the consequences. We have plans to fix this for our Sentry tracing header and will later look again into how we can support traceparent properly.

@jamescrosswell @Flash0ver for now, please get the PR that reverts this out in due time 🙏